Keepalive | SSL

IBM HTTP Server Threads

+

Search Tips   |   Advanced Search

Overview

Apache 2.0 is a thread-based Web server.

Apache 1.3 is a thread-based Web server on the Windows platform. It is a process-based Web server on all UNIX and Linux platforms. This means that it implements the multi-process, single-thread process model: for each incoming request, a new child process is created or requested from a pool to handle it.

However, Apache 2.0, and therefore IBM HTTP Server V6.0 as well, is now a fully thread-based Web server on all platforms. This gives you the following advantages:

• Each request does not requires its own httpd process anymore, and less memory is needed.

• Overall performance improves because in most cases new httpd processes do not need to be created.

• The plug-in load-balancing and failover algorithms work more efficiently in a multi-threaded HTTP server. If one plug-in thread marks an application server unavailable, all other connection threads of the plug-in within the same process will share that knowledge, and will not try to connect to this particular application server again before the RetryInterval has elapsed.

On the UNIX platform, Apache 2.0 also allows you to configure more than one process to be started. This means that the thread model is then changed to multi-process, multi-thread.

Multi-Processing Modules (MPM) architecture

Apache 2.0 achieves efficient support of different operating systems by implementing a Multi-Processing Modules (MPM) architecture, allowing it, for example, to use native networking features instead of going through an emulation layer in Version 1.3.

MPMs are chosen at compile time and differ for each operating system, which implies that the Windows version uses a different MPM module from the AIX or Linux version. The default MPM for Windows is mpm_winnt, whereas the default module for AIX is mpm_worker.

To identify if MPM is compiled into an Apache 2.0 Web server, run the command...

apachectl -l

...which prints out the module names. Look for a module name worker, or a name starting with the mpm prefix.

# ./apachectl -l
Compiled in modules:
  core.c
  worker.c
  http_core.c
  mod_suexec.c
  mod_so.c

The modules are:

• mpm_winnt module

  This Multi-Processing Module is the default for the Windows operating systems. It uses a single control process that launches a single child process that in turn creates all the threads to handle requests.

• mpm_worker module

  This Multi-Processing Module implements a hybrid multi-process multi-threaded server. This is the default module for AIX. By using threads to serve requests, it is able to serve a large number of requests with less system resources than a process-based server. Yet it retains much of the stability of a process-based server by keeping multiple processes available, each with many threads.

The mpm_worker module has proven efficient in many configurations.

IBM Recommendations

This section gives you configuration tips for the UNIX platforms and provides a good starting point for Web server tuning for WebSphere Commerce. Keep in mind that every system and every site has different requirements, so make sure to adapt these settings to your needs.

• ThreadsPerChild

  Each child process creates a fixed number of threads as specified in the ThreadsPerChild directive. The child creates these threads at startup and never creates more. If using an MPM like mpm_winnt, where there is only one child process, this number should be high enough to handle the entire load of the server. If using an MPM like mpm_worker, where there are multiple child processes, the total number of threads should be high enough to handle the common load on the server.

• ThreadLimit

  Set the maximum configured value for ThreadsPerChild for the lifetime of the Apache process. ThreadsPerChild can be modified during a restart up to the value of this directive.

• MaxRequestsPerChild

  Control after how many requests a child server process is recycled and a new one is launched. This was once added to the Apache server to work around memory leaks that have long been fixed. We therefore recommend setting this value to zero (which is the default).

• MaxClients

  This controls the maximum total number of threads that may be launched. This should equal ServerLimit x ThreadsPerChild.

  It a Web server is used only to route requests to an application server, the maximum number of threads needs to be only slightly greater than the number of threads in the application server. The default configuration for WebSphere Commerce, however, requires the Web server to also serve all the static content for your WebSphere Commerce instance. For high performance, we therefore need more threads, as there are typically multiple static requests for each dynamic request.

  Note that the parameter name is misleading, as a client (for example, a browser) typically opens multiple connections so that more than one thread is used per client.

• StartServers

  The number of processes that will initially be launched is set by the StartServers directive.

• MinSpareThreads and MaxSpareThreads

  During operation, the total number of idle threads in all processes will be monitored, and kept within the boundaries specified by MinSpareThreads and MaxSpareThreads.

• ServerLimit

The maximum number of processes that can be launched is set by the ServerLimit directive.

Using a ThreadsPerChild value greater than 512 is not recommended on the Linux and Solaris platform. If 1024 threads are needed, the recommended solution is to increase the ServerLimit value to 2 to launch two server processes with 512 threads each. One or few server processes are best, except Solaris. The ThreadsPerChild should not exceed 500 for Linux, but only 25-100 for Solaris.

Threads and Keepalive

Keepalive sockets require threads to block on them during their lifetime. Therefore, you need to carefully balance the number of sockets, the socket time outs, and the number of threads on each Web server. Too many threads might lead to memory thrashing, too few threads could lead to all threads blocking on idle keepalive connections, forcing new connections to queue waiting for a thread to become available.