Tune web servers
WebSphere Application Server provides plug-ins for several web server brands and versions. Each web server operating system combination has specific tuning parameters that affect the application performance.
Following is a list of tuning parameters specific to web servers. The listed parameters may not apply to all of the supported web servers. Check the web server documentation before using any of these parameters.
Tasks
- Tune IBM HTTP Server 2.0.47.1, Apache 2.0.48, IBM HTTP Server 6.0, and IBM HTTP Server 6.1.
Monitor CPU utilization and check the IBM HTTP Server error_log and http_plugin.log files.
Configure the IBM HTTP Server to show a status page:
- Edit the IHS httpd.conf file and remove the comment character (#) from the following lines in this file:
#LoadModule status_module, modules/ApacheModuleStatus.dll, #<Location/server-status> #SetHandler server-status #</Location>- Save changes and restart the IBM HTTP Server.
- In a web browser, go to: http://your_host/server-status.
Alternatively, click Reload to update status.
- (Optional) If the browser supports refresh, go to refresh every 5 seconds...
http://your_host/server-status?refresh=5
All of these web servers allocate a thread to handle each client connection. Ensuring that enough threads are available for the maximum number of concurrent client connections helps prevent this tier from being a bottleneck. The settings for these web servers can be tuned by making changes to the httpd.conf file on the web server system.
We can check the IBM HTTP Server error_log file to see if there are any warnings about having reached the maximum number of clients (MaxClients). There are several parameters, depending on the specific operating system platform, that determine the maximum number of clients the web server supports.
Support thousands of concurrent clients. It is not unusual for a single IBM HTTP Server system to support thousands of concurrent clients. If our requirements are to support more concurrent clients than the number of threads supported by the web server operating system and hardware, consider using multiple web servers.
Respond to a Connection Refused error message. Some clients might receive a Connection Refused error message if there is a sudden increase in the number of clients. Increasing the ListenBacklog and StartServer parameters can reduce or eliminate this error.
- The ListenBacklog parameter indicates to the operating system the maximum allowed number of pending connections. Although the IBM HTTP Server default is 511, the actual value can be much higher or lower depending on the corresponding operating system parameter. To handle large numbers of simultaneous connections, this parameter and the corresponding OS parameter might need to be set to the number (possibly thousands) of expected simultaneous connections. See the information on tuning operating systems.
- The StartServers parameter indicates the number of IBM HTTP Server processes to initially start. Pre-starting these IBM HTTP Server threads/processes reduces the chance of a user having to wait for a new process to start. We should set this parameter to a value equal to the MinSpareServers parameter so that the minimum number of IBM HTTP Server processes needed for this client load is started immediately.
Prevent the frequent creation and destruction of client threads/processes as the number of users change. We can a use the MinSpareServers and MaxSpareServers to specify the minimum and maximum number of servers (client threads/processes) that can exist in an idle state. To prevent frequent creation and destruction of client threads/processes as the number of users change, set this range large enough to include the maximum number of simultaneous users.
Change the setting on the web server's Access logging parameter to reduce the load on the web server. If we do not need to log every access to the Application Server, change the default value of the web server's Access logging parameter. This change will reduce the load on the web server.
Modify the settings of the Load balancing option and Retry interval web server plug-in properties. We can improve the performance of IBM HTTP Server (with the WebSphere web server plug-in) by modifying the following web server plug-in configuration properties:
- Load balancing option
Specifies the load balancing option that the plug-in uses in sending requests to the various application servers associated with that web server.
The goal of the default load balance option, Round Robin, is to provide an even distribution of work across cluster members. Round Robin works best with web servers that have a single process sending requests to the Application Server. If the web server is using multiple processes to send requests to the Application Server, the Random option can sometimes yield a more even distribution of work across the cluster.
- Retry interval value
Specifies the length of time to wait before trying to connect to a server that has been marked temporarily unavailable.
How can lowering the retry interval affect throughput ? If the plug-in attempts to connect to a particular application server and that application server is offline or in the process of restarting, the requests must wait for a timeout period. This process causes delayed responses for those requests. If we set the retry interval value too high, then an available application server is not utilized.
Specify the retry interval value based on the following factors:
- How long it will take for the application servers to restart
- How averse we are to the delay caused by retrying too often
- How important it is to utilize all of the application servers
Making these changes can help the IBM HTTP Server to support more product users. To modify these properties, in the administrative console, click...
Servers > Server Types > Web Servers > web_server > Plug-in properties > Request routing
Implement a web server plug-in Tune operating systems Web server plug-in tuning tips IBM HTTP Server