Home arrow Apache arrow Page 9 - Building Apache the Way You Want It

Choosing a MultiProcessing Module (Apache 2) - Apache

Have 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).

  1. Building Apache the Way You Want It
  2. Building Apache from Source
  3. General Options
  4. Enabling or Disabling Modules in Bulk
  5. Changing the Module Order (Apache 1.3)
  6. Building Apache from Source As an RPM (Apache 2)
  7. Advanced Configuration
  8. Determining Apacheís Locations Individually
  9. Choosing a MultiProcessing Module (Apache 2)
  10. Building Apache with suExec support
  11. Configuring Apache 2 for Cross-Platform Builds
  12. Configuring the Build Environment
  13. Building Modules with apxs
By: Apress Publishing
Rating: starstarstarstarstar / 14
August 18, 2005

print this article



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.


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


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


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


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


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.

Windows MPMs

The following option is the Windows-based option.


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

DEV_RANDOM: Enables access to the /dev/random device on Unix systems, which is necessary for modules that need a source of randomness. Currently, the only module that needs this is mod_auth_digest, so configure will only enable this rule if mod_auth_digest is included. This is enabled by default.

EXPAT: Incorporate the Expat XML parsing library into Apache for use by modules that process XML. There are no modules in the Apache distribution at the moment that do, but third-party modules such as mod_dav can take advantage of it if present. This rule is enabled by default only if configure finds a lib/expat-lite directory in the src directory. In Apache 2, you can also use --enable-expat or --disable-expat. This is enabled by default since Apache 1.3 onward.

IRIXN32, IRIXNIS: These are specific to SGIís IRIX operating system. IRIX32 causes configure to link against n32 libraries if present. Itís enabled. IRIXNIS applies to Apache systems running on relatively old versions of NIS, also known as Yellow Pages. Itís not enabled. Neither option is of interest to other platforms.

PARANOID: In Apache 1.3, modules are able to specify shell commands that can affect the operation of configure. Normally, configure just reports the event; with the PARANOID rule enabled, configure prints the actual commands executed. Administrators building in third-party modules may want to consider using this and watching the output carefully. This rule isnít enabled by default.

SHARED_CORE: This exports the Apache core into a dynamic module and creates a small bootstrap program to load it. This is only necessary for platforms where Apacheís internal symbols arenít exported, which dynamic modules require to load. The configure script will normally determine whether this is necessary. Itís included by default. This rule is enabled by default.

SHARED_CHAIN: On some platforms, dynamic libraries (which include modules) wonít correctly feed the operating system information about libraries they depend on when Apache is started. For example, mod_ssl requires the SSLeay or OpenSSL library. If itís compiled as a dynamic module, Apache isnít always told that it needs to load the SSL libraries, too. On systems where this problem occurs, enabling the SHARED_CHAIN rule can sometimes fix the problem. On other systems, it may cause Apache to crash, so enable it only if modules are having problems resolving library symbols. This rule is enabled by default.

SOCKS4,SOCKS5: These enable support for the SOCKS4 and SOCKS5 proxy protocols, respectively. If either option is selected, then the appropriate SOCKS library may need to be added to EXTRA_LIBS if configure canít find it. These arenít enabled by default.

WANTHSREGEX: Apache comes with a built-in regular expression engine thatís used by directives such as AliasMatch to do regular expression matching. Some operating systems come with their own regular expression engines that can be used instead if this rule is disabled. configure uses Apacheís own regular expression engine unless the platform-specific configuration indicates otherwise. This rule is enabled by default.

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
LoadModule ssl_module libexec/libssl.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

>>> More Apache Articles          >>> More By Apress Publishing

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Apache Unveils Cassandra 1.2
- Apache on ARM Chips? Dell and Calxeda Help M...
- The Down Side of Open Source Software
- VMware Unveils Serengeti for Apache Hadoop
- SAP Takes Steps to Improve Hadoop Integration
- Looking to Hone Apache Hadoop Skills?
- How to Install Joomla on WAMPP
- Working with XAMPP and Wordpress
- GUI Available for Apache Camel
- Reduce Server Load for Apache and PHP Websit...
- Creating a VAMP (Vista, Apache, MySQL, PHP) ...
- Putting Apache in Jail
- Containing Intrusions in Apache
- Server Limits for Apache Security
- Setting Permissions in Apache

Developer Shed Affiliates


Dev Shed Tutorial Topics: