Web server tuning parameters
WAS 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.
- IBM HTTP Server
The IBM HTTP Server 1.3.28 is a multi-process, single-threaded server.
- Access logs
- Description: Collects all incoming HTTP requests. Logging degrades performance because IO operation overhead causes logs to grow significantly in a short time.
- How to view or set...
- Open the IBM HTTP Server httpd.conf file, located in the directory IBM_HTTP_Server_root_directory/conf.
- Search for a line with the text CustomLog.
- Comment out this line by placing # in front of the line.
- Save and close the httpd.conf file.
- Stop and restart the IBM HTTP Server.
- Default value: Logging of every incoming HTTP request is enabled.
- Recommended value: Disable the access logs.
- Description: The MaxClients directive controls the maximum number of simultaneous connections or users that the web server can service at any one time. If, at peak usage, your web server needs to support 200 active users at once, set MaxClients to 220 (200 plus an extra 10% for load growth). Setting MaxClients too low could cause some users to believe the web server is not responding. You should have sufficient RAM in your web server machines to support each connected client. For IBM HTTP Server 1.3 on Unix, allocate around 1.5MB MaxClients of RAM for use by the IBM HTTP Server. For IBM HTTP Server 1.3 on Windows, allocate around 300KB MaxClients of RAM for use by the IBM HTTP Server. Some third party modules can significantly increase the amount of RAM used per connected client.
- How to view or set: Edit the MaxClients directive in the IBM HTTP Server httpd.conf file, located in the directory IBM_HTTP_Server_root_directory/conf.
- Default value: 150
- Recommended value: The maximum number of users normally simultaneously connected to your web server, plus an additional 10% for buffer. Note: The KeepAliveTimeout setting can affect how long a user is connected to the webserver.
- MinSpareServers, MaxSpareServers, and StartServers
- Description: Pre-allocates and maintains the specified number of processes so that few processes are created and destroyed as the load approaches the specified number of processes. Specifying similar values reduces the CPU usage for creating and destroying HTTPD processes. Adjust this parameter if the time waiting for IBM HTTP Server to start more servers, so that it can handle HTTP requests, is not acceptable.
- How to view or set: Edit the MinSpareServers, MaxSpareServers and StartServers directives in the httpd.conf file located in the IBM_HTTP_Server_root_directory/conf directory.
- Default value: MinSpareServers 5, MaxSpareServers 10, StartServers 5
- Recommended value: For optimum performance, specify the same value for the MinSpareServers and the StartServers parameters. If MaxSpareServers is set to less than MinSpareServers, IBM HTTP Server resets MaxSpareServer=MinSpareServer+1. Setting the StartServers too high can cause swapping if memory is not sufficient, degrading performance.
- Description: Sets the length of a pending connections queue. When several clients request connections to the IBM HTTP Server, and all threads used, a queue exists to hold additional client requests. However, if you use the default Fast Response Cache Accelerator (FRCA) feature of IHS 1.3.28 on Windows, the ListenBackLog directive is not used since FRCA has its own internal queue.
- How to view or set: For non-FRCA: Edit the IBM HTTP Server httpd.conf file. Then, add or view the ListenBackLog directive.
- Default value: For HTTP Server 1.3.28: 1024 with FRCA enabled, 511 with FRCA disabled
- Recommended value: Use the defaults.
- IBM HTTP Server - Linux
- Description: Sets the limit on the number of requests that an individual child server process handles. After the number of requests reaches the value set for the MaxRequestsPerChild parameter, the child process dies. Adjust this parameter if destroying and creating child processes is degrading your Web server performance.
- How to view or set:
- Edit the IBM HTTP server httpd.conf file located in the IBM_HTTP_Server_root_directory/conf directory.
- Change the value of the parameter.
- Save the changes and restart the IBM HTTP server.
- Default value: 500
- Recommended value: Should normally be set to 0. Non-zero settings can be useful if child memory usage is observed to steadly increase over time. Memory leaks have occasionally been observed in third party modules and various OS runtime libraries used by the IBM HTTP Server.
- IBM HTTP Server - Windows 2000 and Windows 2003
- Description: Sets the number of concurrent threads running at any one time within the IBM HTTP Server.
- How to view or set: Edit the IBM HTTP Server file httpd.conf file located in the directory IBM_HTTP_Server_root_directory/conf. Change the value of the parameter. Save the changes and restart the IBM HTTP Server.
There are two ways to find how many threads are used under load:
- Use the Windows 2000 and Windows 2003 Performance Monitor under the desktop Start menu:
- Right-click the status bar on your desktop. Click Task Manager.
- Select the Processes tab.
- Click View > Select Columns.
- Select Thread Count.
- Click OK.
The Processes tab shows the number threads for each process under the column name Threads, including Apache.
- Use the IBM HTTP Server server-status (this choice works on all platforms, not just Windows):
- Edit the IBM HTTP Server httpd.conf file as follows: Remove the comment character # from the following lines: #LoadModule status_module, modules/ApacheModuleStatus.dll, #<Location/server-status>, #SetHandler server-status, and #</Location>.
- Save the changes and restart the IBM HTTP Server.
- In a Web browser, go to the URL: http://yourhost/server-status. Alternatively,
- Click Reload to update status.
- (Optional) If the browser supports refresh, go to http://your_host/server-status?refresh=5 to refresh every five seconds. You will see five requests currently processing 45 idle servers.
- Default value: 50 for IBM HTTP Server 1.3.28.
- Recommended value: Set this value to prevent bottlenecks, allowing just enough traffic through to the appserver.
- Web server configuration reload interval
- Description: Tracks a variety of configuration information about WAS resources. The Web server needs to understand some of this information, such as Uniform Resource Identifiers (URIs) pointing to WAS resources. This configuration data is pushed to the Web server through the WAS plug-in at intervals specified by this parameter. Periodic updates add new servlet definitions without having to restart any of the WAS servers. However, the dynamic regeneration of this configuration information is costly in terms of performance. Adjust this parameter in a stable production environment.
- How to view or set: This parameter, <config RefreshInterval=xxx>, where xxx is the time interval in seconds, is specified in the plugin-cfg.xml file located in the %WAS_HOME%\config\cells directory.
- Default value: The default reload interval is 60 seconds.
- Recommended value: Increase the reload interval to a value that represents an acceptable wait time between the servlet update and the Web server update.
For more information about the plugin-cfg.xml file see the topic plugin-cfg.xml file.
- Sun ONE Web server, Enterprise Edition (formerly iPlanet) - Solaris operating environment
The default configuration of the Sun ONE Web server, Enterprise Edition provides a single-process, multi-threaded server.
- Active threads
- Description: Specifies the current number of threads active in the server. After the server reaches the limit set with this parameter, the server stops servicing new connections until it finishes old connections. If this setting is too low, the server can become throttled, resulting in degraded response times. To tell if the Web server is being throttled, consult its perfdump statistics. Look at the following data:
- WaitingThreads count: If WaitingThreads count is getting close to zero, or is zero, the server is not accepting new connections.
- BusyThreads count: If the WaitingThreads count is close to zero, or is zero, BusyThreads is probably very close to its limit.
- ActiveThreads count: If ActiveThreads count is close to its limit, the server is probably limiting itself.
- How to view or set: Use the Maximum number of simultaneous requests parameter in the Enterprise Server Manager interface to control the number of active threads within Sun ONE Web server, Enterprise Edition. This setting corresponds to the RqThrottle parameter in the magnus.conf file.
- Default value: 512
- Recommended value: Increase the thread count until the active threads parameters show optimum behavior.
- Microsoft Internet Information Server (IIS) - Windows NT and Windows 2000
- IIS permission properties
- Description: The Web server has several properties that dramatically affect the performance of the appserver. The default settings are usually acceptable. However, because other products can change the default settings without user knowledge, make sure to check the IIS settings for the Home Directory permissions of the Web server. The permissions should be set to Script and not to Execute. If the permissions are set to Execute, no error messages are returned, but the performance of WAS is decreased.
- How to view or set: To check or change these permissions, perform the following procedure in the Microsoft management console:
- Select the Web site (usually default Web site).
- Right-click and select the Properties option.
- Click the Home Directory tab. To set the permissions of the Home Directory:
- In the Application settings, select the Script check box in the Permissions list and clear the Execute check box.
- (Optional) Check the permissions of the sePlugin:
- Expand the Web server.
- Right-click the sePlugin and select Properties.
- Confirm that the Execute permissions are set to Execute.
- Default value: Script
- Recommended value: Script
- Number of expected hits per day
- Description: Controls the memory that IIS allocates for connections.
- How to view or set: Using the performance window, set the parameter to More than 100000 in the Web site properties panel of the Microsoft management console.
- Default value: Fewer than 100000
- Recommended value: More than 100000
- ListenBackLog parameter
- Description: Alleviates failed connections under heavy load conditions, if you are using IIS on Windows NT and Windows 2000. Failure typically occurs when you are using more than 100 clients. ListenBackLog increases the number of requests that IIS keeps in its queue. Consider raising this value if you see intermittent Unable to locate server errors in the Netscape browser.
- How to view or set...
- Use a command prompt to issue the regedit command to access the operating system registry.
- In the registry window, locate the parameter in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ InetInfo\Parameters\ListenBackLog directory.
- Right-click the parameter to adjust the setting according to the server load.
- Default value: 25 (decimal)
- Recommended value: Set the ListenBackLog parameter can be set as high as 200, without negative impact on performance and with an improvement in load handling.
Modifying the WebSphere plug-in to improve performance
You can improve the performance of IBM HTTP Server 1.3 (with the WebSphere Web server plug-in) by modifying the plug-in's RetryInterval configuration. The RetryInterval is the length of time to wait before trying to connect to a server that has been marked temporarily unavailable. Making this change can help the IBM HTTP Server 1.3 to scale higher than 400 users.
The plug-in marks a server temporarily unavailable if the connection to the server fails. Although a default value is 60 seconds, it is recommended that you lower this value in order to increase throughput under heavy load conditions. Lowering the RetryInterval is important for IBM HTTP Server 1.3 on UNIX operating systems that have a single thread per process, or for IBM HTTP Server 2.0 if it is configured to have fewer than 10 threads per process.
How can lowering the RetryInterval affect throughput? If the plug-in attempts to connect to a particular appserver while the application server threads are busy handling other connections, which happens under heavy load conditions, the connection times out and the plug-in marks the server temporarily unavailable. If the same plug-in process has other connections open to the same server and a response is received on one of these connections, the server is marked again. However, when you use the IBM HTTP Server 1.3 on a UNIX operating system, there is no other connection since there is only one thread and one concurrent request per plug-in process. Therefore, the plug-in waits for the RetryInterval before attempting to connect to the server again.
Since the application server is not really down, but is busy, requests are typically completed in a small amount of time. The appserver threads become available to accept more connections. A large RetryInterval causes appservers that are marked temporarily unavailable, resulting in more consistent application server CPU utilization and a higher sustained throughput.
Note that Although lowering the RetryInterval can improve performance, if all the application servers are running, a low value can have an adverse affect when one of the appservers is down. In this case, each IBM HTTP Server 1.3 process attempts to connect and fail more frequently, resulting in increased latency and decreased overall throughput.
See AlsoTuning performance parameter index