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
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
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
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 cacheDBM (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)
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:
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.
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.
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
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.