Most HTTP Servers have configuration settings to control how many simultaneous connections they can handle. Once this limit is reached, additional connections will be queued or rejected until a thread becomes ready. In this case, users experience poor response time. Therefore, to avoid HTTP Server becoming the bottleneck in your system, it is important to understand the settings which may affect the connection limit.
IBM HTTP Server includes a status monitor known as mod_status which can be accessed by browser to give a report of current active requests, like this:
One Mistake I made
As I first time experienced the mod_status, I wrongly believed the max. connection number that can be handled by web server is 50 (=1+49) which is much lower than we required. Based on this understanding, I have googled days, and all information I got is to set MaxClients (in httpd.conf )to a high number, like 600, which brings me nothing.
Understand the HTTP Server Instance and its Configuration Directives in Linux
On UNIX and Linux platforms, a running instance of IBM HTTP Server will consist of one single threaded Parent process which starts and maintains one or more multi-threaded Child processes. HTTP requests are received and processed by threads running in the Child processes. Each simultaneous request (TCP connection) consumes a thread. You need to use the appropriate configuration directives to control how many threads the server starts to handle requests and on UNIX and Linux, you can control how the threads are distributed amongst the Child processes. The relationships between them are presented in the following diagram:
Now let's have a look at the HTTP Server config directives (in httpd.conf) to know how they will affect the above HTTP components:
The affected HTTP components HTTP Config Directives (httpd.conf)
Child Processes StartServer: controls how many Child Processes are started when the web server initializes
ServerLimit: the upper limit on the number of child processes.
Thread Max- or Min- SpareThread: affect how the server reacts to changes in server load. To instruct the server to automatically increase the number of Child processes when server load increases (subject to limits imposed by ServerLimit and MaxClients) and to decrease the number of Child processes when server load is low.
ThreadsPerChild: to control how many threads each Child Process starts.
ThreadLimit: upper limit of ThreadsPerChild.
MaxClients: upper limit on the number of simultaneous connections the server can handle.
For example, the following configuration tells IHS to start 2 client processes (StartServers) with each of them 25 threads(ThreadsPerChild), maintain at least 25 spares (MinSpareThreads) at any time. Which means, the the number which is displayed on mod_status is not the max connections number that HTTP Server can handle, but (StartServers * ThreadsPerChild), which is in my case 2*25 =50. When the server load is increased, IHS would add additional capacity, 25 threads at a time, until it hits 600(MaxSpareThreads).
IBM HTTP Server Performance Tuning: http://publib.boulder.ibm.com/httpserv/ihsdiag/ihs_performance.html
Diagnosing Performance Problems for WebSphere Portal 5.1: http://www-1.ibm.com/support/docview.wss?uid=swg27007059