Apache Miscellaneous Documentation

Hints on Running a High-Performance Web Server

Apache HTTP Server Version 1.3

Hints on Running a High-Performance Web Server

Running Apache on a heavily loaded web server, one often encounters problems related to the machine and OS configuration. "Heavy" is relative, of course - but if you are seeing more than a couple hits per second on a sustained basis you should consult the pointers on this page. In general the suggestions involve how to tune your kernel for the heavier TCP load, hardware/software conflicts that arise, etc.

A/UX (Apple's UNIX)
BSD-based (BSDI, FreeBSD, etc)
Digital UNIX
HPUX
Linux
Solaris
SunOS 4.x
SVR4

A/UX (Apple's UNIX)

If you are running Apache on A/UX, a page that gives some helpful performance hints (concerning the listen() queue and using virtual hosts) can be found here

BSD-based (BSDI, FreeBSD, etc)

Quick and detailed performance tuning hints for BSD-derived systems.

Digital UNIX

DIGITAL UNIX Tuning Parameters for Web Servers
We have some newsgroup postings on how to tune Digital UNIX 3.2 and 4.0.

Linux

The most common problem on Linux shows up on heavily-loaded systems where the whole server will appear to freeze for a couple of minutes at a time, and then come back to life. This has been traced to a listen() queue overload - certain Linux implementations have a low value set for the incoming connection queue which can cause problems.

Solaris 2.4

The Solaris 2.4 TCP implementation has a few inherent limitations that only became apparent under heavy loads. This has been fixed to some extent in 2.5 (and completely revamped in 2.6), but for now consult the following URL for tips on how to expand the capabilities if you are finding slowdowns and lags are hurting performance.

SunOS 4.x

More information on tuning SOMAXCONN on SunOS can be found at http://www.islandnet.com/~mark/somaxconn.html.

SVR4

Some SVR4 versions waste three system calls on every gettimeofday() call. Depending on the syntactic form of the TZ environment variable, these systems have several different algorithms to determine the local time zone (presumably compatible with something). The following example uses the central european time zone to demonstrate this:

TZ=:MET

This form delegates the knowledge of the time zone information to an external compiled zoneinfo file (à la BSD).
Caveat: Each time the gettimeofday() function is called, the external zone info is read in again (at least on some SVR4 systems). That results in three wasted system calls with every apache request served.

 open("/usr/lib/locale/TZ/MET", O_RDONLY) = 3
 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 7944) = 778
 close(3)                                = 0

TZ=MET-1MDT,M3.5.0/02:00:00,M10.5.0/03:00:00

This syntax form (à la SYSV) contains all the knowledge about time zone beginning and ending times in its external representation. It has to be parsed each time it is evaluated, resulting in a slight computing overhead, but it requires no system call. Though the table lookup à la BSD is the more sophisticated technical solution, the bad SVR4 implementation makes this the preferred syntax on systems which otherwise access the external zone info file repeatedly.

You should use the truss utility on a single-process apache server (started with the -X debugging switch) to determine whether your system can profit from the second form of the TZ environment variable. If it does, you could integrate the setting of the preferred TZ syntax into the httpd startup script, which is usually simply a copy of (or symbolic link to) the apachectl utility script, or into the system's /etc/TIMEZONE script.

More welcome!

If you have tips to contribute, send mail to apache@apache.org

Apache HTTP Server Version 1.3

Index Home