One of the key innovations arising from the development of Apache 2 is the introduction of a fully multithreaded server core, and the ability to choose from one of several possible cores that implement different strategies for dealing with large numbers of accesses.
The available server cores, known as MPMs, vary depending on the platform youíre going to build Apache on. The greatest choice is available to Unix derivatives such as Linux and MacOS X; the only other platform that provides a choice is OS/2. MPMs are also available for Windows, NetWare, and BeOSóif youíre on one of these platforms, then Apache will automatically choose the appropriate MPM for you.
Remarkably, considering that the MPM is the central component of the server that implements all of the core server directives, the only option you have to worry about when choosing one is the --with-mpm option. For example, to explicitly tell Apache to use the worker MPM, you would use this:
$ ./configure --with-mpm=worker ...
The choice of MPM is closely related to the kind of usage pattern you expect your server to experience, so it is primarily a performance decision. Accordingly, Iíll cover it in detail in Chapter 9 and summarize the configuration directives and build-time definitions in Online Appendix J. For now, Iíll outline the options available with brief notes on their characteristics.
Five MPMs are available for Unix platforms. The prefork and worker MPMs are the two primary choices, offering 1.3 compatibility and support for threads, respectively. Three other MPMs are also available for the more adventurous administrator; leader and threadpool are variants of worker that use different strategies to manage and allocate work to different threads. The perchild MPM is more interesting; it allows different virtual hosts to run under different user and group IDs.prefork
The prefork MPM implements a preforking Apache server with the same characteristics and behavior as Apache 1.3. It doesnít benefit from the performance gains made possible using threads, but itís the most compatible with Apache 1.3 and therefore may offer a more direct and convenient migration route. The following is an example of its usage:
$ ./configure --with-mpm=preforkworker
The worker MPM implements a fully threaded Apache server and is the primary MPM for use on Unix servers. Rather than forking a process for each incoming request, it allocates a thread from an existing process instead. Because threads share code and data, theyíre much more lightweight, and many more can exist concurrently. Theyíre also much faster to start up and shut down. The number of threads allowed to an individual process is limited; once itís reached, a new child process is forked:
$ ./configure --with-mpm=workerleader
The leader MPM is an experimental variant of the worker MPM that uses a different algorithm to divide work up between different threads using the leader/follower design pattern. Although itís structured differently internally, itís almost identical to worker from the point of view of configuration:
$ ./configure --with-mpm=leaderthreadpool
Another experimental variant of the worker MPM, threadpool manages queues of threads and assigns them to incoming connections. In general, usage threadpool isnít as efficient as worker and is primarily used as a development sandbox for testing features before theyíre incorporated into other MPMs:
$ ./configure -with-mpm=threadpoolperchild
The perchild MPM implements an interesting variation of the worker MPM, where a child process is forked for each virtual server configured in the server configuration. Within each process, a variable number of threads are started to handle requests for that host. Because of the alignment of processes to virtual hosts, the child processes can run under the configured user and group for that host, permitting external handlers and filters to run with the correct permissions and obviating the need for the suExec wrapper:
$ ./configure -with-mpm=perchild
Although technically classed as experimental in Apache 2, the perchild MPM is unique in its capability to manage ownerships on a virtual host basis. For administrators who make extensive use of suExec and who want to enable the same permissions controls for mod_perl handlers, PHP pages, and other embedded scripting languages, perchild is the only choice.
The following option is the Windows-based option.winnt
The winnt MPM is the only Windows MPM supplied as standard with Apache 2. It implements a single process, multithreaded server using the threading implementation supported by Windows platforms. Despite its name, it also works fine on Windows 2000 and XP. (Multiple process MPMs arenít practical on Windows platforms because they donít implement anything similar to the fork system call of Unix). The following is an example of its usage:
$ ./configure --with-mpm=winnt
The following option is specific to OS2.
The mpmt_os2 MPM implements a multiprocess (that is, forking), multithreaded server for OS/2. Like the worker MPM, each process contains a limited number of threads, with a new process spawned when the server becomes too busy to allocate a thread from an existing process:
The following are specific to NetWare and BeOS and followed by an example.
The netware MPM provides a multithreaded server on NetWare platforms:
$ ./configure --with-mpm=netware
The beos MPM provides a multithreaded server on BeOS platforms:
./configure --with-mpm=beosRules (Apache 1.3)
Rules are special elements of the Apache 1.3 source that can be enabled or disabled to provide specific features that depend on the platform or other resources being available. These are more specialized options that should generally only be overridden if actually necessary. Apache 2 is quite different internally, so it does away with rules entirely in favor of a more platform-sensitive build environment.
Rules are enabled or disabled with the --enable-rule and --disable-rule options. For example, to enable SOCKS5 proxy support, youíd specify this:
$ ./configure --enable-rule=SOCKS5
The list of rules and whether theyíre enabled, disabled, or default (that is, determined automatically by configure) can be extracted from the output of configure --help. Third-party modules that patch Apacheís source code generally do it by adding a rule; for instance, mod_ssl adds the EAPI rule. The following is the list of standard rules:
On the vast majority of platforms, rules such as SHARED_CHAIN shouldnít need to be set by hand. In the event they are, an alternative and potentially preferable approach to enabling the SHARED_CHAIN rule is to use Apacheís LoadFile directive to have Apache load a library before the module that needs it, for example:
Note that the library on which the module depends should be loaded before the module to allow it to resolve symbols supplied by the library successfully.
You can find a little more information about some of these rules in the Apache 1.3 src/Configuration file. For detailed information on exactly what they do, look for the symbols in the source code, for example:
$ grep -r SOCKS5 apache_1.3.28 | less