<?xml version='1.0' encoding='UTF-8' ?>

<!DOCTYPE manualpage SYSTEM "/style/manualpage.dtd">

<?xml-stylesheet type="text/xsl" href="/style/manual.en.xsl"?>

<manualpage metafile="mpm.xml.meta">

<title>Multi-Processing Modules (MPMs)</title>

<summary>

<p>This document describes what a Multi-Processing Module is and

how they are used by the Apache HTTP Server.</p>

</summary>

<section id="introduction"><title>Introduction</title>

<p>The Apache HTTP Server is designed to be a powerful and

flexible web server that can work on a very wide variety of

platforms in a range of different environments. Different

platforms and different environments often require different

features, or may have different ways of implementing the same

feature most efficiently. Apache httpd has always accommodated a wide

variety of environments through its modular design. This design

allows the webmaster to choose which features will be included

in the server by selecting which modules to load either at

compile-time or at run-time.</p>

<p>Apache HTTP Server 2.0 extends this modular design to the most basic

functions of a web server. The server ships with a selection of

Multi-Processing Modules (MPMs) which are responsible for

binding to network ports on the machine, accepting requests,

and dispatching children to handle the requests.</p>

<p>Extending the modular design to this level of the server

allows two important benefits:</p>

<ul>

<li>Apache httpd can more cleanly and efficiently support a wide

variety of operating systems. In particular, the Windows

version of the server is now much more efficient, since

<module>mpm_winnt</module> can use native

networking features in place of the POSIX layer used in

Apache httpd 1.3. This benefit also extends to other operating

systems that implement specialized MPMs.</li>

<li>The server can be better customized for the needs of the

particular site. For example, sites that need a great deal of

scalability can choose to use a threaded MPM like

<module>worker</module> or <module>event</module>, while sites requiring

stability or compatibility with older software can use a

<module>prefork</module>.</li>

</ul>

<p>At the user level, MPMs appear much like other Apache httpd

modules. The main difference is that one and only one MPM must

be loaded into the server at any time. The list of available

MPMs appears on the <a href="mod/">module index page</a>.</p>

</section>

<section id="defaults"><title>MPM Defaults</title>

<p>The following table lists the default MPMs for various operating

systems. This will be the MPM selected if you do not make another

choice at compile-time.</p>

<table border="1" style="zebra">

<columnspec><column width=".2"/><column width=".2"/></columnspec>

<tr><td>Netware</td><td><module>mpm_netware</module></td></tr>

<tr><td>OS/2</td><td><module>mpmt_os2</module></td></tr>

<tr><td>Unix</td><td><module>prefork</module>, <module>worker</module>, or

<module>event</module>, depending on platform capabilities</td></tr>

<tr><td>Windows</td><td><module>mpm_winnt</module></td></tr>

</table>

<note><p>Here, 'Unix' is used to mean Unix-like operating systems, such as

Linux, BSD, Solaris, Mac OS X, etc.</p></note>

<p>In the case of Unix, the decision as to which MPM is installed is

based on two questions:</p>

<p>1. Does the system support <a

href="http://en.wikipedia.org/wiki/Threads_(computer_science)">threads</a>?</p>

<p>2. Does the system support <a

href="http://en.wikipedia.org/wiki/Polling_(computer_science)">polling</a>?</p>

<p>If the answer to both questions is 'yes', the default MPM is

<module>event</module>.</p>

<p>If The answer to #1 is 'yes', but the answer to #2 is 'no', the

default will be <module>worker</module>.</p>

<p>If the answer to both questions is 'no', then the default MPM will be

<module>prefork</module>.</p>

<p>In practical terms, this means that the default will almost always be

<module>event</module>, as all modern operating systems support these

two features.</p>

</section>

<section id="static"><title>Building an MPM as a static module</title>

<p>MPMs can be built as static modules on all platforms. A single MPM

is chosen at build time and linked into the server. The server must

be rebuilt in order to change the MPM.</p>

<p>To override the default MPM choice, use the

<code>--with-mpm=<em>NAME</em></code> option of the

<program>configure</program> script. <em>NAME</em> is the name of the

desired MPM.</p>

<p>Once the server has been compiled, it is possible to determine which MPM

was chosen by using <code>/httpd -l</code>. This command will list every

module that is compiled into the server, including the MPM.</p>

</section>

<section id="dynamic"><title>Building an MPM as a DSO module</title>

<p>On Unix and similar platforms, MPMs can be built as DSO modules and

dynamically loaded into the server in the same manner as other DSO

modules. Building MPMs as DSO modules allows the MPM to be changed by

updating the <directive module="mod_so">LoadModule</directive> directive

for the MPM instead of by rebuilding the server.</p>

<p>This feature is enabled using the

<code>--enable-mpms-shared</code> option of the <program>configure</program>

script.

With argument <code><em>all</em></code>, all possible MPMs for the platform

will be installed. Alternately, a list of MPMs can be specified as the

argument.</p>

<p>The default MPM, either selected automatically or specified with the

<code>--with-mpm</code> option of the <program>configure</program>

script, will be loaded in the generated server configuration file. Edit the

<directive module="mod_so">LoadModule</directive> directive to select a

different MPM.</p>

</section>

</manualpage>