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...
- There are 10 WAS 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, 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 AlsoConfiguring Web server plug-ins