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. Accept filtering on FreeBSD. 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 There are no known problems with heavily loaded systems running Linux kernels 2.0.32 or later. Earlier kernels have some problems, and an upgrade to the latest 2.0.x is a good idea to eliminate various security and denial of service attacks. 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. Other links: World Wide Web Server Performance, <http://www.sun.com/sun-on-net/performance.html> Solaris 2.x - tuning your TCP/IP stack contains some good technical information about tuning various Solaris TCP/IP parameters. 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 [e-mail] Apache HTTP Server Version 1.3