Performance Overview
This section discusses different server performance considerations in the following topics:
Performance Issues
The first step toward sizing your server is to determine your requirements. Performance means different things to users than it means to webmasters. Users want fast response times (typically less than 100 milliseconds), high availability (no “connection refused” messages), and as much interface control as possible. Webmasters and system administrators, on the other hand, want to see high connection rates, high data throughput, and uptime approaching 100%. In addition, for virtual servers the goal might be to provide a targeted level of performance at different price points. You need to define what performance means for your particular situation.
Here are some areas to consider:
- The number of peak concurrent users
- Security requirements
Encrypting your Web Server’s data streams with SSL makes an enormous difference to your site’s credibility for electronic commerce and other security conscious applications, but it can also seriously impact your CPU load. For more information, see SSL Performance. - The size of the document tree
- Dynamic or static content
The content you serve affects your server’s performance. A Web Server delivering mostly static HTML can run much faster than a server that must execute CGIs for every query.
Configuration
Certain tuning parameters are set at the configuration level, so that every server instance that is based on the configuration has the same tuning information. In addition, some monitoring information is available at the configuration level, so you can monitor the performance of all instances based on the configuration. However, the bulk of the monitoring information is available at the individual server instance, or virtual server level. If you are using a single Web Server instance per configuration, meaning your server is not part of a server farm, the configuration-level statistics show the information for the single server instance based on that configuration.
Virtual Servers
Virtual servers add another layer to the performance improvement process. Certain settings are tunable for the configuration, while others are based on an individual virtual server.
You can also use the quality of service (QoS) features to set resource utilization constraints for an individual virtual server. For example, you can use QoS features to limit the amount of bandwidth and the number of connections allowed for a virtual server. You can set these performance limits, track them, and optionally enforce them.
For more information about using the quality of service features, see Sun Java System Web Server Administrator's Guide.
Server Farms
The clustering features of Web Server allow you to easily deploy to a server farm. Because all servers in a server farm share identical configurations, tuning is not done on a server-by-server basis.
64–Bit Servers
The performance for the 64–bit Web Server is not necessarily better than the performance for the 32–bit Web Server, but the 64–bit server scales better. Because the 32–bit Web Server process is confined to 4 GB of address space, it can run out of address space when attempting to support simultaneous sessions beyond a certain limit. Even if the host machine has available memory and CPU resources, the 32–bit Web Server might not be able to take advantage of it because of the address space limit. The 64–bit Web Server can run more applications and servlets than the 32-bit server. Also, the 64–bit Web Server can cache several GBs of static content, while the 32-bit Web Server is confined to 4 GB of address space.
In general, the tuning for the 64–bit Web Server is similar to the tuning for the 32–bit Web Server. The differences are mostly tuned at the operating system level. Tuning specifics are discussed in Tuning UltraSPARC T1-Based Systems for Performance Benchmarking.
SSL Performance
SSL always has a significant impact on throughput, so for best performance minimize your use of SSL, or consider using a multi-CPU server to handle it.
For SSL, the Web Server uses the NSS library. However, there are other options available for SSL:
- If you are using the Solaris 10 operating system, kernel SSL (KSSL) is available. It does not contain all the algorithms available, as does NSS, but it often provides better performance.
- A cryptographic card hardware accelerator for SSL can also improve performance.
- If you are using the 64–bit Web Server on Solaris, you can use the cryptographic accelerator of the UltraSPARC T1 processor.
Sign up or Log in to add a comment or watch this page.