Five tips for configuring Apache

This article presents five brief tips for tuning and configuring your Apache 1.3 or Apache 2.0 server. We will examine the following strategies: tuning of Apache's accept() serialization, threading with Apache 2.0, SSL session caching with mod_ssl, optimizing the keep-alive timeout values, and examining server load to be able to tune the amount of requests the server can handle.

AcceptMutex
Introduced in Apache 1.3.21 and in Apache 2.0, the AcceptMutex directive reveals a significant opportunity for performance tuning. This directive allows configuration at runtime of how Apache will tune accept() handling. On some systems with only a single listener, accept locking is not required. This strategy is called Single Listen Unserialized Accept (SLUA). However, for those configurations that have multiple listeners or operating systems that have a thundering herd on the accept system call (no matter the number of listeners), the accept routines must be serialized.

Sander Temme of Covalent did some performance analysis of the accept() locking strategies. This report led to the current ordering in Apache 1.3.21 as listed here:

Irix's uslock (uslock)

POSIX cross-process locks (pthread)

SystemV Semaphores (sysvsem)

fcntl() locking (fcntl)

flock() locking (flock)

OS/2 Semaphores (os2sem)

TPF locking (tpfcore)

None

Although it is possible to use AcceptMutex none, your system will be susceptible to the thundering herd problem and deadlocks. These can cause server slowdowns or cause the server to stop responding. The none option is not meant for use on production systems. In informal tests, pthread locks appear to be the best solution. However, pthread cross-process locks are not available on all systems.

Use 2.0 and threading (worker MPM)
One of the main advantages of Apache 2.0 is that it offers the ability to use threading. On certain operating systems, such as Solaris, threading can provide a significant performance improvement. On other operating systems, such as Linux, the improvement may not be as substantial.

Under Apache 2.0, the strategy for dealing with requests has been abstracted out into Multi Process Model (MPM). The old Apache 1.3 model is represented with the prefork MPM and is the default MPM for 2.0 on Unix platforms. A separate process handles each connection. However, if you compile Apache 2.0 with the --with-mpm=worker option, server requests will be handled by threads. This approach will significantly reduce the overhead of handling requests on operating systems with good threading implementations.

SSL session cache
If you are using mod_ssl, an add-on module for Apache 1.3 and included in Apache 2.0, you can gain a significant performance improvement by using a session cache. This improvement will dramatically reduce the overhead of SSL connections. There are three ways to set up your session cache:

DBM (dbm), a common format for storing items on a disk (htpasswd can storepasswords in DBM format)

Shared memory Cyclic Buffer (shm or shmcb)

Shared memory Hash table (shmht)

For each of these options, you provide a path to a file. For the DBM variant, the file will be written to disk. For the shared memory variants, that file will be used as a backing store for the operating system's preferred shared memory mechanism. Keep in mind that most operating systems do not allow shared memory segments to be on network-mounted drives, such as NFS, so this path should be local to the server.

The recommended option is to use shared memory, but the DBM variant can be used on those platforms that do not have shared memory.

KeepAliveTimeout
Imagine a user reading a page on your site, and then clicking on a link to another page on your site. If this transaction occurs within the KeepAliveTimeout period (defaults to 15 seconds), a new TCP connection does not have to be created to the server. This can greatly reduce the overhead on your machine. However, the worker will not be able to handle any more requests in that time frame. After KeepAliveTimeout period of inactivity, the worker will be able to handle a new incoming request from a different client. Therefore, you may have to increase the number of request processes or threads available in order to compensate for the idle request. This value should be tuned carefully to determine what works for your site.

Using mod_status
By using mod_status to examine server load, you can retrieve valuable information that can help tune the overall server. The example in Listing A provides the necessary directives for httpd.conf.

In Listing A, any requests from 127.0.0.1 or any machine that has a double-reversed domain name example.com will be allowed to view the server's status by going to /server-status. All other requests will be denied. Of course, you should replace .example.com or 127.0.0.1 with correct information for your site. Note that some operating systems will make requests coming from the local machine appear to Apache as coming from the configured external IP address instead of 127.0.0.1.
The command apachectl status provides a quick way of examining the server status. If the output does not consistently show available workers, it would be best to increase the MinSpareServers or MinSpareThreads value (on threaded MPMs for Apache 2.0). You may need to increase the MaxClients value accordingly.