|
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 |
|
|
|
|
|
|