On
UNIX and Linux platforms, a running instance of IBM HTTP Server
will consist of one single threaded
-
StartServers
The
StartServers directive controls how many Child Processes are started when the web server initializes. The recommended value is 1. Do not set this higher than MaxSpareThreads divided by ThreadsPerChild. Otherwise, processes will be started at initialization and terminated immediately thereafter. Every second, IHS checks if new child processes are needed, so generally tuning of StartServers will be moot as early as a minute after IHS has started.
-
ServerLimit
There is a built-in upper limit on the number of child processes. At runtime, the actual upper limit on the number of child processes is
MaxClients
divided by ThreadsPerChild
.This should only be changed when you have reason to change MaxClients or ThreadsPerChild, it does not directly dictate the number of child processes created at runtime.
It is possible to see more child processes than this if some of them are gracefully stopping. If there are many of them, it probably means that MaxSpareThreads is set too small, or that MaxRequestsPerChild is non-zero and not large enough; see below for more information on both these directives.
-
ThreadsPerChild
Use the
ThreadsPerChild directive to control how many threads each Child process starts. More information on strategies for distributing threads amongst child processes is included below. -
ThreadLimit
ThreadsPerChild
has a built in upper limit. Use ThreadLimit to increase the upper limit of ThreadsPerChild. The value of ThreadLimit affects the size of the shared memory segment the server uses to perform inter-process communication between the parent and child processes. Do not increase ThreadLimit beyond what is required for ThreadsPerChild. -
MaxClients
The
MaxClients directive places an upper limit on the number of simultaneous connections the server can handle. MaxClients should be set according to the expected load.
The
Setting MaxSpareThreads to a relatively small value has a performance penalty: Extra CPU to terminate and create child processes. During normal operation, the load on the server may vary widely (e.g., from 150 busy threads to 450 busy threads). If MaxSpareThreads is smaller than this variance (e.g., 450-150=300), then the web server will terminate and create child processes frequently, resulting in reduced performance.
Recommended settings:
Directive | Value |
ThreadsPerChild | Leave at the default value, or increase to a larger proportion
of MaxClients for better coordination of WebSphere Plugin
processing threads (via less child processes). Larger
ThreadsPerChild (and fewer processes) also results in fewer
dedicated web container threads being used by the ESI invalidation
feature of the WebSphere Plugin.
Increasing ThreadsPerchild too high on heavily loaded SSL servers may incur more CPU and throughput issues, as there is additional contention for memory. |
MaxClients | maximum number of simultaneous connections, rounded up to an even multiple of ThreadsPerChild |
StartServers | 2 |
MinSpareThreads | The greater of "25" or 10% of MaxClients integer. Since IHS
checks this value approximately once per second, MinSpareThreads
should safely exceed the number of new requests you might receive
in a second.
Setting MinSpareThreads too high with the WebSphere Plugin may trigger premature spawning of new child processes, for which AppServer requests will be distributed over, with no sharing of MaxConnections counts or markdowns. If the ESI invalidation servlet is configured in the WebSphere Plugin, each additional process results in a dedicated web container thread being consumed. Setting MinSpareThreads too low may induce delays of a few seconds if IHS runs out of processing threads. |
MaxSpareThreads | There are multiple approaches to the tuning of this directive:
Set MaxSpareThreads to 25-30% of MaxClients. If it is too small a fraction of MaxClients, child processes will be terminated and recreated frequently. |
ServerLimit | MaxClients divided by ThreadsPerChild, or the default if that is high enough |
ThreadLimit | ThreadsPerChild |
Note: ThreadLimit and ServerLimit need to appear before these other directives in the configuration file.
Default settings in recent default configuration files:
ThreadLimit 25 ServerLimit 64 StartServers 2 MaxClients 600 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0
1.3.1. If
memory is constrained
If there is concern about available memory on the server, some additional tuning can be done.
Increasing ThreadsPerChild (and ThreadLimit) will reduce the number of total server processes needed, reducing the per-server memory overhead. However, there are a number of possible drawbacks to increasing ThreadsPerChild. Search this document for ThreadsPerChild and consider all the warnings before changing it. Notably, this increases the per-process footprint which can be detrimental on 32-bit httpds.
On Linux, VSZ can appear very large if ulimit -s is left as a large value or unlimited. Reduce it in bin/envvars to e.g. 512 with ulimit -s if this is a concern. A high VSZ has no real cost, it does not consume memory, but it is sometimes noticed.
Setting and MaxMemFree to e.g. 512, will limit memory retained by each thread.
WebSphere plug-in concerns on Linux and Unix systems
>5.1 Tuning
IHS to make the MaxConnections parameter more effective
The use of
the
It is usually much more effective to actively prevent backend systmes from accepting more connections than they can reliably handle, performing throttling at the TCP level. When this is done at the client (HTTP Plugin) side, there is no cross-system or cross-process coordination which makes the limits ineffective.
- linuxthreads (traditional pthread library on Linux): ThreadsPerChild greater than about 100 results in high CPU overhead
- SSL on any platform: threadsPerChild greater than about 100 results in high CPU overhead
- WebSphere 5.x plug-in has a file descriptor limitation which will be encountered on Linux and Solaris if ThreadsPerChild is greater than 500
Using MaxConnections with more then 1 child processes, or across a webserver farm, introduces a number of complications. Each IHS child process must have a high enough MaxConnections value to allow each thread to be able to find a backend server, but in aggregate the child processes should not be able to overrun an individual application server.
Choosing a value for MaxConnections
-
MaxConnections has no effect if it exceeds ThreadsPerChild, because no child could try to use that many connections in the first place.
-
Upper limit
If you are concerned about a single HTTP Server overloading an Application server, you must first determine "N" -- the maximum number of requests the single AppServer can handle.
MaxConnections would then be = (N / (MaxClients / ThreadsPerChild)), or N divided by the maximum number of child processes based on your configuration . This represents the worst-case number of connections by IHS to a single Application Server. As the number of backends grows, the likelyhood of the worst-case scenario decreases as even the uncoordinated child processes are still distributing load with respect to session affinity and load balancing.
For example, if you wish to restrict each Application Server to a total of 200 connections, spread out among 4 child processes, you must set the MaxConnections parameter to 50 because each child process keeps its own count.
-
Lower Limit
If MaxConnections is too small, a child process may start returning errors because it has no AppServers to use.
To prevent problems, MaxConnections * (number of usable backend servers) should exceed
ThreadsPerChild
.For example, if each child process has 128
ThreadsPerChild
and MaxConnections is only 50 with two backend AppServers, a single child process may not be able to fulfill all 128 requests because only 50 * 2 connections can be made.
To use MaxConnections, IHS should be configured to use a small, fixed number of child process, and to not vary them in response to a change in load. This provides a consistent, predictable number of child processes that each have a fixed MaxConnections parameter.
- MinSpareServers and MaxSpareServers should be set to the same value as MaxClients.
- StartServers should be set to MaxClients / ThreadsPerChild.
When more then 1 child process is configured (number of child processes is MaxClients/ThreadsPerChild), setting MaxSpareServers equal to MaxClients can have the effect of keeping multiple child process alive when they aren't strictly needed. This can be considered detrimental to the WebSphere Plugin detecting markdowns, because the threads in each child process must discover a server should be marked down. See section 6.2 below.