Choosing a MultiProcessing Module (Apache 2) - ApacheHave you ever wanted to customize Apache? This article will help you get started on building a customized version of Apache to suit your own needs. It is taken from chapter three of the book Pro Apache third edition, written by Peter Wainwright (Apress, 2004; ISBN: 1590593006).
print this article SEARCH DEV SHED |
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. Unix MPMs 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. preforkThe 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=prefork workerThe 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=worker leaderThe 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=leader threadpoolAnother 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=threadpool perchildThe 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. Windows MPMs The following option is the Windows-based option. winntThe 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 OS/2 MPMs 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: --with-mpm=mpmt_os2 Others The following are specific to NetWare and BeOS and followed by an example. netware The netware MPM provides a multithreaded server on NetWare platforms: $ ./configure --with-mpm=netware beos The beos MPM provides a multithreaded server on BeOS platforms: ./configure --with-mpm=beos Rules (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: LoadFile /usr/lib/libopenssl.so 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
|
|
|
|
|
|
|
|
