MaxConnections parameter support in WebSphere Application Server V4.0 and V5.0 plug-in.
 Technote (FAQ)
 
Problem
Configuring the number of pending HTTP connections to an application server in the WebSphere® Application Server V4.0 and V5.0 plug-in.
 
Cause
Configuring the WebSphere Application Server plug-in with the MaxConnections parameter in plugin-cfg.xml to limit the number of pending connections to application servers.
 
Solution

Statement of Support
WebSphere Application Server V4.0.2 through the V4.0.6 HTTP plug-in will support the use of the MaxConnections element in plugin-cfg.xml after the cumulative plug-in fix, dated 23 June 2003, or later, is installed.

WebSphere Application Server V5.0 through the V5.0.1 HTTP plug-in supports use of the MaxConnections element in plugin-cfg.xml after the cumulative plug-in fix dated 1 July 2003, or later, is installed.

IBM recommends using IBM® HTTP Server V2.0 rather than IBM HTTP Server V1.3, whenever possible.


Background
WebSphere Application Server V4.0.2 through V4.0.6 supports Random or Basic Round Robin mechanism for selecting application servers for load-balancing and failover. WebSphere Application Server V5.0. through V5.0.1 HTTP supports Weighted Round Robin.

The number of active connections to an application server (AppServer) that the plug-in handles equals the number of active user threads in WebContainer plus the Connection BackLog of WebContainer. Assuming that two clones (Clone 1 and Clone 2) exist in a cloned or clustered environment, it is possible that the Connection BackLog for Clone 1 has built up and Clone 2 is nearly idle. A WebSphere administrator might notice that the Java™ Virtual Machine (JVM) of Clone 1 has a significantly higher CPU than the JVM of Clone 2, primarily because of the large Connection BackLog. (For this particular scenario, it is assumed that no deadlock exists in the customer's code that could result in hung threads in WebContainer.) It does not prevent the plug-in, through Round Robin or Random routing algorithm, from sending a new incoming HTTP request to Clone 1, although the preferred route should be to Clone 2.

Another possible scenario is that Clone 2 is running on a more powerful server than Clone 1. If so, the WebSphere administrator should adjust the WebSphere Application Server plug-in setting so that Clone 2 has more pending connections than Clone 1, in case the workload should need it.

Based on customer requests, the new LIDB2879 was added for WebSphere Application Server V4.0 releases and LIDB2867 for WebSphere Application Server V5.0 features the plug-in logic so that an AppServer selection can limit the number of connections to the AppServer.


Considerations when setting MaxConnections in the WebSphere Application Server plug-in
The plug-in code was enhanced so that a WebSphere administrator can limit the number of pending connections to an AppServer by using the new MaxConnections attribute in plugin-cfg.xml.

Internally, the plug-in counts the number of pending requests for the AppServer. If the request is sent to the AppServer, then this counter is increased by 1. If the request is received from the AppServer, then the counter is decreased by 1. When the plug-in needs to select a server, if the value of the counter is greater than the MaxConnections value, then the server is not selected. If no other servers can be selected, the request ends and issues the HTTP return code 503.

An example of MaxConnections setting in plugin-cfg.xml:

<ServerGroup Name="PLUGINCLUSTER">
<Server CloneID="ujsv71f3" Name="host1_server1"  MaxConnections="50">
<Transport Hostname="host1" Port="9080" Protocol="http"/>
</Server>
<Server CloneID="ujsvembh" Name="host2_server1" MaxConnections="100">
<Transport Hostname="host2" Port="9081" Protocol="http"/>
</Server>
</ServerGroup>


Deciding between an IBM HTTP Server V2.0 single-processing or multiprocessing environment
Because IBM HTTP Server V2.0 allows more than one process to be started, consider the following trade-offs before setting IBM HTTP Server V2.0 to use a single-processing or multiprocessing environment.

In a multiprocess environment, each process loads the WebSphere Application Server plug-in configuration file and communicates with the application server independently. When the Edge Side Include (ESI) processor is enabled within the plug-in (which is the default), it works very well in a process model where IBM HTTP Server starts only one process. The content that a process caches is not shared with another process. When multiple processes exist, configuration data and internal variables that track pending connections for one process are not visible to other processes because the memory is not shared. It might influence a performance if the plug-in was changed to use a shared memory to track of number of pending connections to an AppServer. In addition, load-balancing and connection-pooling algorithms work more efficiently.

However, valid reasons also exist for using configurations that run multiple child processes. One example is more robust operation if a child process goes down abnormally. Although the plug-in can work in multiprocessing configurations, its load-balancing and connection-pooling algorithms work less efficiently and the ESI cache is not shared among child processes.

Each system is unique and has different optimum parameter settings. If you decide to configure a single-processing environment, you can use the following examples as guidelines of changes you can make to the httpd.conf file to guarantee that IBM HTTP Server follows a threading model and starts only one process.
  • For UNIX®, IBM recommends the worker MPM model:

    <IfModule worker.c>
    ServerLimit
    1
    ThreadLimit
    1024
    StartServers
    1
    MaxClients
    1024
    MinSpareThreads
    1
    MaxSpareThreads
    1024
    ThreadsPerChild
    1024
    MaxRequestsPerChild
    0
    </IfModule>

  • Linux® and Solaris platforms:
    Note: ThreadsPerChild 1024 is not a valid configuration with the WebSphere Application Server V5.0 or V5.1 plug-in on Linux or Solaris systems. The plug-in on those platforms does not handle file descriptors larger than 1024, and with that many threads it is inevitable that such file descriptors will be used by the plug-in for communication with WebSphere Application Server. ThreadsPerChild must be kept to 500 or less. (Larger numbers of IBM HTTP Server log files would result in more file descriptors in use, so ThreadsPerChild should be even smaller.)

  • Linux platforms:
    For RedHat Advanced Server 2.1, SuSE SLES 8, and other supported platforms which use the linuxthreads thread library, IBM testing suggests customers use values NO higher than 100 for ThreadsPerChild on this level of Linux in order to avoid performance issues in the thread library.

  • For Windows, IBM recommends the WINNT MPM model:

    <IfModule mpm_winnt.c>
    ThreadsPerChild
    2048
    MaxRequestsPerChild
    0
    </IfModule>

As stated above, the plug-in will also handle a scenario where a WebSphere administrator wants to start more than one process in the Web server--meaning, not strictly follow the threading model--or in the previously mentioned process-based IBM HTTP Server/Apache V1.3.19. or V1.3.26 releases on UNIX platforms. In this instance, a WebSphere administrator should set MaxConnections equal to the number of connections divided by the number of processes. The plug-in issues the HTTP return code 503 when the number of pending requests is between the number of connections divided by the number of processes plus the number of connections. Remember that the plug-in will issue the HTTP error code 503 only when no other AppServers capable of serving the HTTP request exist.

Using an example for the multiprocess Web server model, consider the following scenario, which assumes that you are using a single AppServer in WebSphere domain with no clones. Set the number of servers (the number of processes) started to 3. Set the maximum limit of connections that the AppServer handles (the number of connections) to 300. Then set the value of MaxConnections to 100 (300 divided by 3). Each process acts on its own, and it can pick up requests in any URI pattern. The plug-in that runs on each process returns the HTTP return code 503 when it has reached the MaxConnections value, which in this case is 100. The following illustrates two extreme examples--namely, when 301 pending requests exist for the AppServer. To keep it simple, it is assumed that the AppServer has not responded to all the HTTP requests.
  • Example 1:
    If Process1 picks up all HTTP requests, then the plug-in issues the HTTP error code 503 for the 101st request.

  • Example 2:
    If three processes pick up all requests using the round-robin algorithm, then the plug-in issues the HTTP error code 503 for the 301st request.

    So the plug-in issues the HTTP return code 503 when the number of pending requests is between 100 and 300.


Conclusion
This document can help WebSphere system administrators with additional WebSphere Application Server plug-in tuning for pending connections to WebSphere AppServers. If you are currently using a process-based Web server, IBM recommends migrating to a thread-based Web server, such as IBM HTTP Server V2.0.42 release or above whenever possible. Once you have done this, IBM recommends (it is not a must) to configure the Web server settings so that IBM HTTP Server V2.0 strictly follows the threading model with only one process started.

For more information about the benefits of running the thread-based IBM HTTP Server V2.0 Web server on UNIX platforms with WebSphere Application Server, see the following technote: IBM HTTP Server V2.0 support with WebSphere Application Server V4.0
 
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Plug-in
Operating system(s): HP-UX
Software version: 4.0
Software edition:
Reference #: 1113964
IBM Group: Software Group
Modified date: Mar 16, 2005