Web server plug-in tuning tips

During normal operation, the backlog of connections pending to an application server is bound to grow. Therefore, balancing workloads among application servers in a network fronted by a WebSphere Web server plug-in helps 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.

In a z/OS environment, WAS V5 uses native Workload Management (WLM) functionality to dynamically balance the workload of the Application Servers within a cluster. The MaxConnections attribute is not the optimal choice for load balancing in a z/OS environment.

The capacity of the Application Servers in the network determines the value you specify for the MaxConnections attribute in theplugin-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...

Depending on the request arrival pattern, all requests to Application_1 might be forwarded to two of the nodes, say 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 httpd.conf to the indicated values...

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

 

See Also

Configuring Web server plug-ins