Open Source

Tailor Apache to suit your site using multiprocessing modules

Apache 2.0's multiprocessing modules allow the open source Web server to be scaled to meet the needs of enterprise-level Web servers. Scott Lowe explains these MPMs and shows how to compile them into Apache.


There are a number of new features to consider before actually deploying the latest version of Apache's popular Web server, Apache 2.0. Among these features are multiprocessing modules (MPMs), which are responsible for binding network ports on the machine, accepting requests, and dispatching "children" to handle the requests. These features allow administrators to compile and install a Web server that can handle their organization's needs. For example, if your Web site needs a great deal of scalability, you could use the threaded worker MPM because of its ability to intuitively increase or decrease processes.

In this Daily Drill Down, I will discuss the various Apache MPMs and show how they are compiled into Apache. All my examples here were performed on a Red Hat Linux 7.2 server running Apache 2.0.35.

Why use MPMs?
The newest version of Apache uses MPMs to better customize the performance of the Web server in regard to what kind of Web site is required. Apache 2.0 ships with a number of MPMs that bind to network ports on the Web server, accept requests for the server, and then dispatch either child processes or threads, depending on the need, to handle the requests. This is better than simply using the static request handler of older versions of Apache for a couple of reasons.

First, by using MPMs, Apache can support a wider array of operating systems without significant performance loss. While Apache 1.x could run on Windows servers, the Apache team did not recommended doing so because of performance issues. This performance loss was largely because Apache was implemented on Windows using the POSIX layer, resulting in less than stellar performance. With the release of Apache 2.0, the Web server performance matches that of IIS, but without the security holes. This performance boost is due to the use of the winnt_mpm, which allows native Windows networking features to be used instead of relying on Windows’ POSIX subsystem.

Using MPMs also allows Apache to be tightly tuned to a specific environment. For example, if a large financial services company is using Apache and their Web site will require very high availability or needs to be compatible with legacy software, they may opt to use a preforking MPM, which behaves similarly to that of the older Apache 1.3. On the other hand, if the company needs its site to be highly scalable, it may choose to use the worker MPM.]

The available MPMs
Apache 2.0.35 currently ships with a few standard MPMs. Below is a listing of the standard modules and a description of each.
  • ·        mpm_netware—This is an MPM that implements a threaded Web server optimized for NetWare.
  • ·        mpm_winnt—This MPM module is optimized for Windows and utilizes native networking calls rather than using the POSIX subsystem like in previous versions of Apache for Windows. It's the default MPM used on Windows.
  • ·        perchild—This MPM allows individual processes serving requests to use different user IDs. In Apache 2.0.35, this is still an experimental module and doesn't work yet on most platforms. With this MPM, a fixed number of processes are created and additional connections are handled by creating additional threads in those processes.
  • ·        prefork—Use this to make your Apache server a nonthreaded preforking Web server. This is the default UNIX MPM and is similar to the behavior of Apache 1.3. This helps to create a Web site that is highly available. With this MPM, a single control process is responsible for creating child processes to serve requests.
  • ·        worker—This MPM implements a hybrid multiprocess, multithreaded Web server. Just the opposite of perchild, the worker MPM creates a fixed number of threads per process, which listen for connections. When more processing is required, additional processes are created with the same number of threads as the others. When processes are no longer needed, they are killed. This allows for a Web site that is more scalable.

Installing a multiprocessing module
Unlike other Apache modules, only one MPM can be installed at a given time and it needs to be installed at Apache compile time (meaning when running the ./configure command before the make ; make install process). The steps below assume that you have downloaded Apache 2.0.35, that you've placed it in /usr/src, and that you're logged in as root:
  • ·        cd /usr/src—Use this command to switch to the src directory
  • ·        gunzip -dc httpd-2.0.35.tar.gz | tar xvf -This command unpacks the Apache 2.0.35 archive.
  • ·        ./configure —prefix=/usr/local/apache2 —with-mpm=worker—This command configures the Apache installer to install Apache into /usr/local/apache2 and to use the worker MPM.
  • ·        make—To build the binaries to be used in the installation, use this command. This process takes a bit longer than it used to with Apache 1.3.x.
  • ·        make installThis command installs the Apache binaries.
  • ·        cd /usr/local/apache2/binUse this to switch to the Apache bin directory.
  • ·        ./apachectl startThis starts up the Apache Web server.

You will know if the installation of the Apache 2.0 Web server was successful if you can browse to it, and you receive the Apache Web server test page. But, how do you know that the MPM that you installed is actually running? By running the command /usr/local/apache2/bin/httpd -L, you can get a list of all of the installed modules.

The output from this command on my machine is shown in Listing A.

About halfway down the list, you'll notice the worker.c module. This is the code that runs the worker MPM that shows which modules are installed and running. You won't actually notice any difference in the function of your Apache server until it becomes more heavily loaded, and only then if you're actually comparing it to another Apache server that's been configured differently.

Configuring the worker MPM
Once you've installed the worker MPM and verified that it's running, you can configure its operating parameters. Each MPM has a section in the Apache configuration file—in this instance, /usr/local/apache2/conf/httpd.conf—where parameters are stored. For the worker MPM, below is a listing of the values you can modify to suit your needs. These parameters are in the httpd.conf section that begins with <IfModule worker.c>:
  • ·        StartServersThis parameter indicates the initial number of server processes that will be started when the Web server starts. The default is 2.
  • ·        MaxClients—Use this parameter to set the maximum number of simultaneous client connections. The default is 150.
  • ·        MinSpareThreads—This parameter sets the minimum number of “spare” threads to retain in case one is needed to boost performance. The default is 25.
  • ·        MaxSpareThreads—When a server is not using all available threads, keeping spare threads is a waste of system resources. This value determines the maximum number of threads that can be kept spare. The default is 75
  • ·        ThreadsPerChild—This indicates the number of threads in each process. The default is 25.
  • ·        MaxRequestsPerChild—This is the number of threads that a server process will serve. Keep in mind that when using this MPM, the server process simply spawns children to handle requests and doesn't handle any itself, which is why this value is zero. The default is 0.

You can easily modify the parameters of your Web server using the worker MPM with these parameters. Want to have your server start with 100 threads instead of 50 to handle a larger load? Just change the StartServers value to 4. (Multiply the StartServers number by the ThreadsPerChild value to get a total thread count. For example, a StartServers value of 4 multiplied by a ThreadsPerChild value of 25 equals 100).

Compiling in a different MPM
Picture this: You compiled and installed Apache 2.0 a few weeks ago and simply took the default installation of the prefork MPM. You now realize that you should have installed the worker MPM instead to make your site more scalable. You could correct this situation by recompiling Apache with the worker MPM. Before you do, back up your configuration files and site content. Apache is pretty good about not overwriting this information when you reinstall it, but you can never be too safe.

Once you’ve backed up Apache, run the configuration/installation process again but with the proper MPM and any pertinent parameters. Your Apache installation will then be ready to scale.

Other MPM parameters
Every MPM uses a different set of parameters, but each set is derived from a complete list of parameters. Some of the parameters are used by more than one MPM. Table A lists each parameter and shows which parameters are used by which MPM.
Table A

MPMs

Parameter

netware

perchild

prefork

winnt

worker

CoreDumpDirectory

u

Group

u

u

Listen

u

ListenBackLog

u

LockFile

u

u

MaxClients

u u

u

MaxRequestsPerChild

MaxSpareThreads

u u u

MaxSpareServers

u u

u u

MaxThreads

u u u u

MaxThreadsPerChild

u

u u

MinSpareServers

u u

u u

MinSpareThreads

u u

NumServers

u

u u u

PidFile

u

ScoreBoardFile

u

u

SendBufferSize

u

ServerLimit

u u

u

StartServers

u u

u

StartThreads

u u u

ThreadsPerChild

u u u

ThreadStackSize

u u u u

For clarification, below is a description of the most widely used parameters:
  • ·        MaxClients—This parameter configures the maximum number of server processes that are allowed to start on the Web server. Under the worker MPM, this is the maximum number of client connections.
  • ·        MaxRequestsPerChild—This parameter configures the maximum number of requests that a server process will serve. Note that this is zero for most MPMs as they use other methods to handle requests instead of each process handling them.
  • ·        MaxSpareThreads—This is the maximum number of idle threads. The way that this is handled is dependent on how the MPM being used handles threads. For example, the worker MPM maintains spare threads on a server-wide basis while the perchild MPM maintains them on a per process basis.
  • ·        MaxThreads—This parameter sets the maximum number of worker threads allowed.
  • ·        MaxThreadsPerChild—This parameter sets the maximum number of threads that will be created in each child process.
  • ·        MinSpareThreads—This parameter is the same as MaxSpareThreads, but specifies the minimum number of threads that are kept spare.
  • ·        NumServers—This parameter sets the number of child processes allowed to live at the same time. This number is not modified dynamically, so this value needs to be high enough to handle all connections.
  • ·        StartServers—This parameter sets the number of child server processes that will be used at startup.
  • ·        StartThreads—This parameter sets the number of threads each child process will create at startup.
  • ·        ThreadsPerChild—This parameter sets the number of threads created at startup by each child process.
  • ·        ThreadStackSize—This parameter sets the number of the stack size to use for each running thread.

It's not as difficult as it appears
Although it's easy to get confused with the various MPMs and their respective parameters, remember it is just a matter of installing Apache with the desired MPM/parameter combination. Take a look at the tables above, decide which MPM you need, apply the necessary parameters, and run the configuration and installation steps.

Editor's Picks

Free Newsletters, In your Inbox