Performance Tuning IBM HTTP Server documentation
Pertains to UNIX users

Looking at the Apache V2.0 process model in the IBM HTTP Server

When the Apache parent process starts, it forks a number of child processes. Each of these child processes creates a number of threads which are responsible for accepting connections off of the listening sockets. When the system receives a connection, the system wakes up one of the threads to handle the connection. Each Apache thread can handle one connection.
For example, Apache needs 1000 threads to handle 1000 concurrently connected clients, or connections.

Controlling the number of IBM HTTP Server threads

You can use several configuration directives to control the number of IBM HTTP Server threads, or the number of concurrently supported clients. The most important directives follow:

  • StartServers
    Specifies the initial number of child processes to start when the server starts. Apache automatically increases the number of child processes as server load increases. The maximum number of child processes is the setting for MaxClients, divided by the setting for ThreadsPerChild.
  • MaxClients
    Specifies the maximum number of Apache processes that can run at once. Limiting the number of Apache processes can prevent overrunning your hardware capabilities. Some installations will need to use the ServerLimit directive to allow a large setting for MaxClients.
  • ThreadsPerChild
    Specifies the number of threads that will be created in each child process. Some installations will need to use the ThreadLimit directive to allow a large setting for ThreadsPerChild.

Affecting availability of IBM HTTP Server processes to handle requests using the KeepAlive feature

HTTP V1.1 has a feature known as Connection KeepAlive. In a non-KeepAlive connection, the browser starts a TCP connection and sends a single request to the server. The server responds and then takes down the connection. Each request includes the bring-up and take down of a TCP connection. The KeepAlive feature maintains connections for a number of requests, controlled by configuration directives. This control reduces network overhead related to startup and tear down of TCP connections. The server assumes that for a KeepAlive connection, the browser sends another request. The server attempts to read the next request off the network. When the next request becomes unavailable, the process blocks on the read, waiting for the next request.

Consider a typical scenario where a user goes to a Web site resulting in the fetching and rendering of an information page on the browser. The user lingers while reading the page. The user does not actively request more pages, but the server blocks on a network read waiting for the next request. This blocked process becomes unavailable to handle requests from other clients. The user can follow a link off the Web site, get a cup of coffee and never send another request. You can configure the IBM HTTP Server to wait a specific time for the next request using:

  • KeepAliveTimeout
    The default equals 15 seconds. This setting means the server stops waiting for the next request, shuts down the connection to the inactive client and makes the process available to handle other requests.

Some heavily loaded sites disable the KeepAlive feature entirely.

Assess the needs of your site and set KeepAliveTimeout appropriately. Give the browser enough time to request all the elements of a page over the KeepAlive connection, but not wait too long for the user to initiate the next page request. Some recommend setting KeepAliveTimeout to 5 seconds as a good compromise between balancing available processes with minimizing network I/O.

Setting expiration dates on static content

You can reduce connection requests to your site by setting document expiration dates with mod_expires. If the browser has cached a previous visit, this action can save another connection request to your site.

 
Finding related information

     (Back to the top)