IBM HTTP Server 1.3
The IBM HTTP Server v1.3.x (IHS) is a multi-process, single-threaded server (except on the Windows platform). Some factors related to the IBM HTTP Server performance have already been covered in Web server. This section provides additional information.
Modifying the WebSphere plug-in to improve performance
You can improve the performance of IBM HTTP Server (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 to scale higher than 400 users.
The plug-in marks a server temporarily unavailable if the connection to the server fails. Although the 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 appserver is not really down, but is busy, requests are typically completed in a small amount of time. The application server threads become available to accept more connections. A large RetryInterval causes application servers that are marked temporarily unavailable, resulting in more consistent application server CPU utilization and a higher sustained throughput
Note Although lowering the RetryInterval can improve performance, if all the appservers are running, a low value can have an adverse affect when one of the application servers is down. In this case, each IBM HTTP Server 1.3 process attempts to connect and fails more frequently, resulting in increased latency and decreased overall throughput. |
.
TCP initial connect timeout
If, on the other hand, an appserver is really unavailable because of a node outage, the time each plug-in process waits for a connect is defined by the underlying operating system's TCP initial connect timeout. So each plug-in process will have to wait for that timeout before marking an application server temporarily unavailable. This timeout value differs for every operating system. In Windows 2000 it is comparatively short and adjusted per TCP session to match the characteristics of the connection. For detailed information refer to Microsoft Knowledge Base Article #170359. On AIX this value can be queried and set using the no command. Its default value for AIX 5.2, for example, is 75 seconds.
In a scenario where a single-threaded, multi-process Web server is used (for example, IBM HTTP Server 1.3) the plug-in processes do not share information about application server status. Therefore each process will try to connect to the appserver until it times out. Lowering the TCP initial connect timeout in AIX to a smaller value will improve this specific behavior. Keep in mind that, when changing this value, all processes using the TCP stack will be affected, and this might produce unwanted side effects. Using a value too small might accomplish the opposite, when connections are no longer established under high load because the client thinks his connection partner to be unavailable, when in fact the latter is just busy and would respond in due while. If you change this parameter, be sure to perform a load test and watch how your systems behave under peak load! For detailed instructions on using no, refer to the AIX man-page or the administration manual.
Note The value for tcp_keepinit has to be specified in halfseconds. Refer to Example 19-5, where the TCP initial connect timeout value is set from 75 to 10 seconds. For instructions on how to accomplish this in other operating systems, please refer to their administration manuals, respectively. |
Example 19-5 Querying and setting network options in AIX
$ no -o tcp_keepinit
tcp_keepinit = 150
$ no -o tcp_keepinit=20
$ no -o tcp_keepinit
tcp_keepinit = 20
Attention: Since WAS V5.x the Web server plug-in supports the new ConnectTimeout parameter. This attribute is valid inside the <server> tag of plugin-cfg.xml and lets you bypass the operating system's TCP initial connect timeout. You can specify how long to wait until the currently queried appserver is marked unavailable. This is the recommended procedure and preferred to changing the operating system's TCP initial connect timeout value. Refer to 5.7.3, Tuning failover for a detailed description of the ConnectTimeout parameter. |
Access logs
All incoming HTTP requests are logged here. Logging degrades performance because I/O operation overhead causes logs to grow significantly in a short time.
To turn logging on or off, edit the IBM HTTP Server httpd.conf file, located in the directory <IBM HTTP Server Home>/conf. Search for a line with the text CustomLog. Comment out this line, then save and close the httpd.conf. file. Stop and restart the IBM HTTP Server. By default, logging is enabled, but for better performance it is recommended that you disable the access logs.
MaxClients/ThreadsPerChild
The value of the MaxClients parameter can significantly impact the application, particularly if it is too high. More is not always better. The optimum value depends on the application. Setting MaxClients too high can cause swapping if there is insufficient RAM. Set this value to prevent bottlenecks, allowing just enough traffic through to the appserver.
The maximum number of concurrent requests accepted by the IBM HTTP Server is configured by a parameter in the httpd.conf configuration file. The parameter sets the number of concurrent threads running at any one time within the IBM HTTP Server. The default value is 150.
The parameter keyword is different on different platforms. On IBM HTTP servers running on the UNIX platform, the keyword is MaxClients. On the Windows platform, the configuration parameter keyword is ThreadsPerChild. Refer to ThreadsPerChild for more information about this parameter on Windows platforms.
To configure the number of maximum concurrent allowed connections, open the httpd.conf file and change the value of ThreadsPerChild (Windows) or MaxClients (UNIX) to the appropriate value, as seen in Example 19-6. Save the changes and restart the IBM HTTP server.
Example 19-6 ThreadsPerChild/MaxClients parameter in httpd.conf
# Number of concurrent threads at a time (set the value to more or less
# depending on the responsiveness you want and the resources you wish
# this server to consume).
MaxClients 50
MinSpareServers, MaxSpareServers, and StartServers
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 (based on MinSpareServers). 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.
For optimum performance, specify the same value for the MaxSpareServers 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.
To view or change these values, edit the following directives in the file httpd.conf, located in the directory <IBM HTTP Server Home>/conf:
| MinSpareServers |
| MaxSpareServers |
| StartServers |
Default values are MinSpareServers 5, MaxSpareServers 10, and StartServers 5.
For more information about tuning IHS, see "Hints on Running a High-Performance Web Server" at:
http://www.ibm.com/software/webservers/httpservers/doc/v136/misc/perf.html
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
AIX is a trademark of the IBM Corporation in the United States, other countries, or both.