<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>Hints on Running a High-Performance Web Server</TITLE>
</HEAD>

<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
 BGCOLOR="#FFFFFF"
 TEXT="#000000"
 LINK="#0000FF"
 VLINK="#000080"
 ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
<H1 ALIGN="CENTER">Hints on Running a High-Performance Web Server</H1>

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.

<UL>
<LI><A HREF="#AUX">A/UX (Apple's UNIX)</A>
<LI><A HREF="#BSD">BSD-based (BSDI, FreeBSD, etc)</A>
<LI><A HREF="#DEC">Digital UNIX</A>
<LI><A HREF="perf-hp.html">HPUX</A>
<LI><A HREF="#Linux">Linux</A>
<LI><A HREF="#Solaris">Solaris</A>
<LI><A HREF="#SunOS">SunOS 4.x</A>
<LI><A HREF="#SVR4">SVR4</A>
</UL>

<HR>

<H3><A NAME="AUX">
A/UX (Apple's UNIX)
</A></H3>

If you are running Apache on A/UX, a page that gives some helpful
performance hints (concerning the <EM>listen()</EM> queue and using
virtual hosts)
<A HREF="http://www.jaguNET.com/apache.html">can be found here</A>

<P><HR>

<H3><A NAME="BSD">
BSD-based (BSDI, FreeBSD, etc)
</A></H3>

<A HREF="perf-bsd44.html#initial">Quick</A> and
<A HREF="perf-bsd44.html#detail">detailed</A>
performance tuning hints for BSD-derived systems.

<P><HR>

<H3><A NAME="DEC">
Digital UNIX
</A></H3>

<UL>
  <LI><A
       HREF="http://www.digital.com/info/internet/document/ias/tuning.html"
      >DIGITAL UNIX Tuning Parameters for Web Servers</A>
  <LI>We have some <A HREF="perf-dec.html">newsgroup postings</A> on how
      to tune Digital UNIX 3.2 and 4.0.
</UL>

<P><HR>

<H3><A NAME="Linux">
Linux
</A></H3>

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.

<P><HR>

<H3><A NAME="Solaris">
Solaris 2.4
</A></H3>

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.

<P>

Other links:

<UL>

<LI><A HREF="http://www.sun.com/sun-on-net/performance.html">
World Wide Web Server Performance,
&lt;http://www.sun.com/sun-on-net/performance.html&gt;</A>
<LI><A HREF="http://www.rvs.uni-hannover.de/people/voeckler/tune/EN/tune.html">
Solaris 2.x - tuning your TCP/IP stack</A> contains some good technical
information about tuning various Solaris TCP/IP parameters.
</UL>

<P><HR>

<H3><A NAME="SunOS">
SunOS 4.x
</A></H3>

More information on tuning SOMAXCONN on SunOS can be found at
<A HREF="http://www.islandnet.com/~mark/somaxconn.html">
http://www.islandnet.com/~mark/somaxconn.html</A>.

<P><HR>

<H3><A NAME="SVR4">
SVR4
</A></H3>

Some SVR4 versions waste three system calls on every
<SAMP>gettimeofday()</SAMP> call. Depending on the syntactic
form of the <SAMP>TZ</SAMP> environment variable, these
systems have several different algorithms to determine the
local time zone (presumably <EM>compatible</EM> with
something). The following example uses the central european
time zone to demonstrate this:
<DL>
 <DT><STRONG>TZ=:MET</STRONG>
 <DD>This form delegates the knowledge of the time zone
     information to an external compiled zoneinfo file
     (&agrave; la BSD).<BR>
     <STRONG>Caveat:</STRONG> 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.<PRE>
     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</PRE>

 <DT><STRONG>TZ=MET-1MDT,M3.5.0/02:00:00,M10.5.0/03:00:00</STRONG>
 <DD>This syntax form (&agrave; 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 &agrave; 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.
</DL>
You should use the <SAMP>truss</SAMP> utility on a
single-process apache server (started with the <SAMP>-X</SAMP>
debugging switch) to determine whether your system can profit
from the second form of the <SAMP>TZ</SAMP> environment
variable. If it does, you could integrate the setting of the
preferred <SAMP>TZ</SAMP> syntax into the httpd startup
script, which is usually simply a copy of (or symbolic link
to) the <SAMP>apachectl</SAMP> utility script, or into the
system's <SAMP>/etc/TIMEZONE</SAMP> script.

<P><HR>

<H3>More welcome!</H3>

If you have tips to contribute, send mail to <A
HREF="mailto:apache@apache.org">apache@apache.org</A>

<!--#include virtual="footer.html" -->
</BODY></HTML>