Web server plug-in tuning tips

During normal operation, the backlog of connections pending to an application server can increase. Therefore, balancing the application server workload across a cluster can improve request response time.

In a distributed environment, you can use the MaxConnections server attribute in the Web server plug-in configuration file (plugin-cfg.xml) to define the maximum number of connections that can be pending to any of the application servers in the cluster. When this maximum number of connections is reached, the plug-in, when establishing connections, automatically skips that Application Server, and tries the next available application server. If no application servers are available, an HTTP 503 response code will be returned.

The capacity of the application servers in the network determines the value you specify for the MaxConnections attribute in the plugin-cfg.xml file. The ideal scenario is for all of the application servers in the network to be optimally utilized. For example, if you have the following environment:

• There are 10 WebSphere Application Server nodes in a cluster.
• All of these nodes host the same applications (that is, Application_1 and Application_2).
• This cluster of nodes is fronted by five IBM HTTP Servers.
• The IBM HTTP Servers get requests through a load balancer.
• Application_1 takes approximately 60 seconds to respond to a request.
• Application_2 takes approximately 1 second to respond to a request.

Depending on the request arrival pattern, all requests to Application_1 might be forwarded to two of the nodes, such as node_1 and node_2. If the arrival rate is faster than the processing rate, the number of pending requests to node_1 and node_2 can grow.

Eventually, node_1 and node_2 are busy and are not able to respond to future requests. It usually takes a long time to recover from this overloaded situation.

If you want to maintain 2500 connections, and optimally utilize the Application Servers in this example, set the MaxConnections attribute in the plugin-cfg.xml file to 50. (This value is arrived at by dividing the number of connections by the result of multiplying the number of Application Servers by the number of Web servers; in this example, 2500/(10x5)=50.)

The MaxConnections attribute works best with Web servers that follow the threading model instead of the process model, and only one process is started.

The IBM HTTP Server V1.3.x follows the process model. With the process model, a new process gets created to handle each connection from the Application Server, and typically, one process handles only one connection to the Application Server. Therefore, the MaxConnections attribute does not have much of an impact in restricting the number of concurrent requests to the Application Server.

The IBM HTTP Server V2.0.x follows the threading model. To prevent the IBM HTTP Server from starting more than one process, change the following properties in the Web server configuration file (httpd.conf) to the indicated values:

ServerLimit           1
ThreadLimit           4000
StartServers          1
MaxClients            1024
MinSpareThreads       1
MaxSpareThreads       1024
ThreadsPerChild       1024
MaxRequestsPerChild   0