perf-tuning.html revision cceb8f42ca47214278463c4042b32ff29ee162c6
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
c0c934808d1b7d058148814255f32064a0e09555lin wang - Sun Microsystems - Beijing China "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<html xmlns="http://www.w3.org/1999/xhtml">
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <meta name="generator" content="HTML Tidy, see www.w3.org" />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <title>Apache Performance Notes</title>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China vlink="#000080" alink="#FF0000">
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <!--#include virtual="header.html" -->
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <strong>Warning:</strong> This document has not been fully updated
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China to take into account changes made in the 2.0 version of the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Apache HTTP Server. Some of the information may still be
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China relevant, but please use it with care.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h1 align="center">Apache Performance Notes</h1>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Author: Dean Gaudet</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <li><a href="#introduction">Introduction</a></li>
3ae945c326c1fc078149f2c8b11fac0cc8f6d1d6lin wang - Sun Microsystems - Beijing China <li><a href="#hardware">Hardware and Operating System
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <li><a href="#runtime">Run-Time Configuration Issues</a></li>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <li><a href="#compiletime">Compile-Time Configuration
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <li><a href="#trace">Detailed Analysis of a
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <table border="1">
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <td valign="top"><strong>Related Modules</strong><br />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <a href="/mod/mod_dir.html">mod_dir</a><br />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <a href="/mod/mpm_common.html">Multi-Processing
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China module</a><br />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <a href="/mod/mod_status.html">mod_status</a><br />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <td valign="top"><strong>Related Directives</strong><br />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China href="/mod/core.html#allowoverride">AllowOverride</a><br />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China href="/mod/mod_dir.html#directoryindex">DirectoryIndex</a><br />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China href="/mod/core.html#hostnamelookups">HostnameLookups</a><br />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China href="/mod/core.html#enablemmap">EnableMMAP</a><br />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China href="/mod/core.html#keepalivetimeout">KeepAliveTimeout</a><br />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China href="/mod/prefork.html#maxspareservers">MaxSpareServers</a><br />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China href="/mod/prefork.html#mixspareservers">MinSpareServers</a><br />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <a href="/mod/core.html#options">Options</a>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China (FollowSymLinks and FollowIfOwnerMatch)<br />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China href="/mod/mpm_common.html#startservers">StartServers</a><br />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h3><a id="introduction"
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China name="introduction">Introduction</a></h3>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Apache 2.0 is a general-purpose webserver, designed to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China provide a balance of flexibility, portability, and performance.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Although it has not been designed specifically to set benchmark
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China records, Apache 2.0 is capable of high performance in many
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China real-world situations.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Compared to Apache 1.3, release 2.0 contains many additional
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China optimizations to increase throughput and scalability. Most of
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China these improvements are enabled by default. However, there are
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China compile-time and run-time configuration choices that can
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China significantly affect performance. This document describes the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China options that a server administrator can configure to tune the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China performance of an Apache 2.0 installation. Some of these
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China configuration options enable the httpd to better take advantage
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China of the capabilities of the hardware and OS, while others allow
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China the administrator to trade functionality for speed.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h3><a id="hardware" name="hardware">Hardware and Operating
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China System Issues</a></h3>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>The single biggest hardware issue affecting webserver
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China performance is RAM. A webserver should never ever have to swap,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China swapping increases the latency of each request beyond a point
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China that users consider "fast enough". This causes users to hit
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China stop and reload, further increasing the load. You can, and
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China should, control the <code>MaxClients</code> setting so that
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China your server does not spawn so many children it starts
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Beyond that the rest is mundane: get a fast enough CPU, a
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China fast enough network card, and fast enough disks, where "fast
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China enough" is something that needs to be determined by
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China experimentation.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Operating system choice is largely a matter of local
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China concerns. But some guidelines that have proven generally
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <li>Run the latest stable release and patchlevel of the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China operating system that you choose. Many OS suppliers have
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China introduced significant performance improvements to their
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China TCP stacks and thread libraries in recent years.</li>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <li>If your OS supports a sendfile(2) system call, make
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China sure you install the release and/or patches needed to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China enable it. (With Linux, for example, this means using
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Linux 2.4 or later. For early releases of Solaris 8,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China you may need to apply a patch.) On systems where it
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China is available, sendfile enables Apache 2 to deliver
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China static content faster and with lower CPU utilization.</li>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h3><a id="runtime" name="runtime">Run-Time Configuration
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h4>HostnameLookups</h4>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Prior to Apache 1.3, <code>HostnameLookups</code> defaulted
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China to On. This adds latency to every request because it requires a
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China DNS lookup to complete before the request is finished. In
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Apache 1.3 this setting defaults to Off. However (1.3 or
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China later), if you use any <code>Allow from domain</code> or
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>Deny from domain</code> directives then you will pay for
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China a double reverse DNS lookup (a reverse, followed by a forward
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China to make sure that the reverse is not being spoofed). So for the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China highest performance avoid using these directives (it's fine to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China use IP addresses rather than domain names).</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Note that it's possible to scope the directives, such as
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China within a <code><Location /server-status></code> section.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China In this case the DNS lookups are only performed on requests
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China matching the criteria. Here's an example which disables lookups
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China except for .html and .cgi files:</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing ChinaHostnameLookups off
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<Files ~ "\.(html|cgi)$">
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China HostnameLookups on
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China But even still, if you just need DNS names in some CGIs you
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China could consider doing the <code>gethostbyname</code> call in the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China specific CGIs that need it.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Similarly, if you need to have hostname information in your
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China server logs in order to generate reports of this information,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China you can postprocess your log file with <a
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China href="/programs/logresolve.html">logresolve</a>, so that
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China these lookups can be done without making the client wait. It is
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China recommended that you do this postprocessing, and any other
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China statistical analysis of the log file, somewhere other than your
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China production web server machine, in order that this activity does
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China not adversely affect server performance.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h4>FollowSymLinks and SymLinksIfOwnerMatch</h4>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Wherever in your URL-space you do not have an <code>Options
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China FollowSymLinks</code>, or you do have an <code>Options
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China SymLinksIfOwnerMatch</code> Apache will have to issue extra
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China system calls to check up on symlinks. One extra call per
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China filename component. For example, if you had:</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing ChinaDocumentRoot /www/htdocs
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<Directory />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Options SymLinksIfOwnerMatch
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China</Directory>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China and a request is made for the URI <code>/index.html</code>.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Then Apache will perform <code>lstat(2)</code> on
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>/www</code>, <code>/www/htdocs</code>, and
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>/www/htdocs/index.html</code>. The results of these
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>lstats</code> are never cached, so they will occur on
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China every single request. If you really desire the symlinks
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China security checking you can do something like this:
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing ChinaDocumentRoot /www/htdocs
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<Directory />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Options FollowSymLinks
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China</Directory>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<Directory /www/htdocs>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Options -FollowSymLinks +SymLinksIfOwnerMatch
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China</Directory>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China This at least avoids the extra checks for the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>DocumentRoot</code> path. Note that you'll need to add
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China similar sections if you have any <code>Alias</code> or
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>RewriteRule</code> paths outside of your document root.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China For highest performance, and no symlink protection, set
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>FollowSymLinks</code> everywhere, and never set
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>SymLinksIfOwnerMatch</code>.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h4>AllowOverride</h4>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Wherever in your URL-space you allow overrides (typically
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>.htaccess</code> files) Apache will attempt to open
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>.htaccess</code> for each filename component. For
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing ChinaDocumentRoot /www/htdocs
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<Directory />
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China AllowOverride all
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China</Directory>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China and a request is made for the URI <code>/index.html</code>.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Then Apache will attempt to open <code>/.htaccess</code>,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>/www/.htaccess</code>, and
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>/www/htdocs/.htaccess</code>. The solutions are similar
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China to the previous case of <code>Options FollowSymLinks</code>.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China For highest performance use <code>AllowOverride None</code>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China everywhere in your filesystem.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h4>Negotiation</h4>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>If at all possible, avoid content-negotiation if you're
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China really interested in every last ounce of performance. In
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China practice the benefits of negotiation outweigh the performance
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China penalties. There's one case where you can speed up the server.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Instead of using a wildcard such as:</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing ChinaDirectoryIndex index
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Use a complete list of options:
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing ChinaDirectoryIndex index.cgi index.pl index.shtml index.html
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China where you list the most common choice first.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Also note that explicitly creating a <code>type-map</code>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China file provides better performance than using
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>MultiViews</code>, as the necessary information can be
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China determined by reading this single file, rather than having to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China scan the directory for files.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h4>Memory-mapping</h4>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>In situations where Apache 2.0 needs to look at the contents
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China of a file being delivered--for example, when doing server-side-include
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China processing--it normally memory-maps the file if the OS supports
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China some form of mmap(2).
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>On some platforms, this memory-mapping improves performance.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China However, there are cases where memory-mapping can hurt the performance
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China or even the stability of the httpd:</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <li>On some operating systems, mmap does not scale as well as
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China read(2) when the number of CPUs increases. On multiprocessor
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Solaris servers, for example, Apache 2.0 sometimes delivers
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China server-parsed files faster when mmap is disabled.</li>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <li>If you memory-map a file located on an NFS-mounted filesystem
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China and a process on another NFS client machine deletes or truncates
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China the file, your process may get a bus error the next time it tries
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China to access the mapped file content.</li>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>For installations where either of these factors applies, you
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China should use <code>EnableMMAP off</code> to disable the memory-mapping
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China of delivered files. (Note: This directive can be overridden on
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China a per-directory basis.)</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h4>Process Creation</h4>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Prior to Apache 1.3 the <code>MinSpareServers</code>,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>MaxSpareServers</code>, and <code>StartServers</code>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China settings all had drastic effects on benchmark results. In
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China particular, Apache required a "ramp-up" period in order to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China reach a number of children sufficient to serve the load being
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China applied. After the initial spawning of
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>StartServers</code> children, only one child per second
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China would be created to satisfy the <code>MinSpareServers</code>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China setting. So a server being accessed by 100 simultaneous
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China clients, using the default <code>StartServers</code> of 5 would
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China take on the order 95 seconds to spawn enough children to handle
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China the load. This works fine in practice on real-life servers,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China because they aren't restarted frequently. But does really
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China poorly on benchmarks which might only run for ten minutes.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>The one-per-second rule was implemented in an effort to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China avoid swamping the machine with the startup of new children. If
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China the machine is busy spawning children it can't service
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China requests. But it has such a drastic effect on the perceived
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China performance of Apache that it had to be replaced. As of Apache
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China 1.3, the code will relax the one-per-second rule. It will spawn
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China one, wait a second, then spawn two, wait a second, then spawn
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China four, and it will continue exponentially until it is spawning
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China 32 children per second. It will stop whenever it satisfies the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>MinSpareServers</code> setting.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>This appears to be responsive enough that it's almost
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China unnecessary to twiddle the <code>MinSpareServers</code>,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>MaxSpareServers</code> and <code>StartServers</code>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China knobs. When more than 4 children are spawned per second, a
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China message will be emitted to the <code>ErrorLog</code>. If you
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China see a lot of these errors then consider tuning these settings.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Use the <code>mod_status</code> output as a guide.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Related to process creation is process death induced by the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>MaxRequestsPerChild</code> setting. By default this is 0,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China which means that there is no limit to the number of requests
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China handled per child. If your configuration currently has this set
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China to some very low number, such as 30, you may want to bump this
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China up significantly. If you are running SunOS or an old version of
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Solaris, limit this to 10000 or so because of memory leaks.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>When keep-alives are in use, children will be kept busy
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China doing nothing waiting for more requests on the already open
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China connection. The default <code>KeepAliveTimeout</code> of 15
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China seconds attempts to minimize this effect. The tradeoff here is
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China between network bandwidth and server resources. In no event
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China should you raise this above about 60 seconds, as <a
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China href="http://www.research.digital.com/wrl/techreports/abstracts/95.4.html">
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China most of the benefits are lost</a>.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h3><a id="compiletime" name="compiletime">Compile-Time
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Configuration Issues</a></h3>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h4>mod_status and ExtendedStatus On</h4>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>If you include <code>mod_status</code> and you also set
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>ExtendedStatus On</code> when building and running
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Apache, then on every request Apache will perform two calls to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>gettimeofday(2)</code> (or <code>times(2)</code>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China depending on your operating system), and (pre-1.3) several
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China extra calls to <code>time(2)</code>. This is all done so that
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China the status report contains timing indications. For highest
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China performance, set <code>ExtendedStatus off</code> (which is the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h4>accept Serialization - multiple sockets</h4>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>This discusses a shortcoming in the Unix socket API. Suppose
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China your web server uses multiple <code>Listen</code> statements to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China listen on either multiple ports or multiple addresses. In order
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China to test each socket to see if a connection is ready Apache uses
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>select(2)</code>. <code>select(2)</code> indicates that a
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China socket has <em>zero</em> or <em>at least one</em> connection
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China waiting on it. Apache's model includes multiple children, and
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China all the idle ones test for new connections at the same time. A
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China naive implementation looks something like this (these examples
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China do not match the code, they're contrived for pedagogical
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China fd_set accept_fds;
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China FD_ZERO (&accept_fds);
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China for (i = first_socket; i <= last_socket; ++i) {
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China FD_SET (i, &accept_fds);
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China if (rc < 1) continue;
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China new_connection = -1;
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China for (i = first_socket; i <= last_socket; ++i) {
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China if (FD_ISSET (i, &accept_fds)) {
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China new_connection = accept (i, NULL, NULL);
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China if (new_connection != -1) break;
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China if (new_connection != -1) break;
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China process the new_connection;
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China But this naive implementation has a serious starvation problem.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Recall that multiple children execute this loop at the same
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China time, and so multiple children will block at
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>select</code> when they are in between requests. All
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China those blocked children will awaken and return from
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>select</code> when a single request appears on any socket
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China (the number of children which awaken varies depending on the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China operating system and timing issues). They will all then fall
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China down into the loop and try to <code>accept</code> the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China connection. But only one will succeed (assuming there's still
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China only one connection ready), the rest will be <em>blocked</em>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China in <code>accept</code>. This effectively locks those children
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China into serving requests from that one socket and no other
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China sockets, and they'll be stuck there until enough new requests
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China appear on that socket to wake them all up. This starvation
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China problem was first documented in <a
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China href="http://bugs.apache.org/index/full/467">PR#467</a>. There
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China are at least two solutions.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>One solution is to make the sockets non-blocking. In this
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China case the <code>accept</code> won't block the children, and they
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China will be allowed to continue immediately. But this wastes CPU
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China time. Suppose you have ten idle children in
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>select</code>, and one connection arrives. Then nine of
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China those children will wake up, try to <code>accept</code> the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China connection, fail, and loop back into <code>select</code>,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China accomplishing nothing. Meanwhile none of those children are
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China servicing requests that occurred on other sockets until they
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China get back up to the <code>select</code> again. Overall this
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China solution does not seem very fruitful unless you have as many
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China idle CPUs (in a multiprocessor box) as you have idle children,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China not a very likely situation.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Another solution, the one used by Apache, is to serialize
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China entry into the inner loop. The loop looks like this
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China (differences highlighted):</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <strong>accept_mutex_on ();</strong>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China fd_set accept_fds;
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China FD_ZERO (&accept_fds);
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China for (i = first_socket; i <= last_socket; ++i) {
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China FD_SET (i, &accept_fds);
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China if (rc < 1) continue;
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China new_connection = -1;
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China for (i = first_socket; i <= last_socket; ++i) {
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China if (FD_ISSET (i, &accept_fds)) {
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China new_connection = accept (i, NULL, NULL);
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China if (new_connection != -1) break;
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China if (new_connection != -1) break;
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <strong>accept_mutex_off ();</strong>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China process the new_connection;
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <a id="serialize" name="serialize">The functions</a>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>accept_mutex_on</code> and <code>accept_mutex_off</code>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China implement a mutual exclusion semaphore. Only one child can have
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China the mutex at any time. There are several choices for
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China implementing these mutexes. The choice is defined in
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>src/conf.h</code> (pre-1.3) or
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>src/include/ap_config.h</code> (1.3 or later). Some
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China architectures do not have any locking choice made, on these
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China architectures it is unsafe to use multiple <code>Listen</code>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <dt><code>USE_FLOCK_SERIALIZED_ACCEPT</code></dt>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <dd>This method uses the <code>flock(2)</code> system call to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China lock a lock file (located by the <code>LockFile</code>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China directive).</dd>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <dt><code>USE_FCNTL_SERIALIZED_ACCEPT</code></dt>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <dd>This method uses the <code>fcntl(2)</code> system call to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China lock a lock file (located by the <code>LockFile</code>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China directive).</dd>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <dt><code>USE_SYSVSEM_SERIALIZED_ACCEPT</code></dt>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <dd>(1.3 or later) This method uses SysV-style semaphores to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China implement the mutex. Unfortunately SysV-style semaphores have
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China some bad side-effects. One is that it's possible Apache will
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China die without cleaning up the semaphore (see the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>ipcs(8)</code> man page). The other is that the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China semaphore API allows for a denial of service attack by any
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China CGIs running under the same uid as the webserver
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China (<em>i.e.</em>, all CGIs, unless you use something like
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China suexec or cgiwrapper). For these reasons this method is not
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China used on any architecture except IRIX (where the previous two
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China are prohibitively expensive on most IRIX boxes).</dd>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <dt><code>USE_USLOCK_SERIALIZED_ACCEPT</code></dt>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <dd>(1.3 or later) This method is only available on IRIX, and
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China uses <code>usconfig(2)</code> to create a mutex. While this
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China method avoids the hassles of SysV-style semaphores, it is not
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China the default for IRIX. This is because on single processor
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China IRIX boxes (5.3 or 6.2) the uslock code is two orders of
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China magnitude slower than the SysV-semaphore code. On
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China multi-processor IRIX boxes the uslock code is an order of
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China magnitude faster than the SysV-semaphore code. Kind of a
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China messed up situation. So if you're using a multiprocessor IRIX
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China box then you should rebuild your webserver with
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>-DUSE_USLOCK_SERIALIZED_ACCEPT</code> on the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>EXTRA_CFLAGS</code>.</dd>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <dt><code>USE_PTHREAD_SERIALIZED_ACCEPT</code></dt>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <dd>(1.3 or later) This method uses POSIX mutexes and should
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China work on any architecture implementing the full POSIX threads
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China specification, however appears to only work on Solaris (2.5
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China or later), and even then only in certain configurations. If
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China you experiment with this you should watch out for your server
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China hanging and not responding. Static content only servers may
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China work just fine.</dd>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>If your system has another method of serialization which
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China isn't in the above list then it may be worthwhile adding code
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China for it (and submitting a patch back to Apache).</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Another solution that has been considered but never
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China implemented is to partially serialize the loop -- that is, let
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China in a certain number of processes. This would only be of
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China interest on multiprocessor boxes where it's possible multiple
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China children could run simultaneously, and the serialization
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China actually doesn't take advantage of the full bandwidth. This is
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China a possible area of future investigation, but priority remains
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China low because highly parallel web servers are not the norm.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Ideally you should run servers without multiple
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>Listen</code> statements if you want the highest
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China performance. But read on.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h4>accept Serialization - single socket</h4>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>The above is fine and dandy for multiple socket servers, but
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China what about single socket servers? In theory they shouldn't
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China experience any of these same problems because all children can
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China just block in <code>accept(2)</code> until a connection
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China arrives, and no starvation results. In practice this hides
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China almost the same "spinning" behaviour discussed above in the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China non-blocking solution. The way that most TCP stacks are
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China implemented, the kernel actually wakes up all processes blocked
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China in <code>accept</code> when a single connection arrives. One of
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China those processes gets the connection and returns to user-space,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China the rest spin in the kernel and go back to sleep when they
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China discover there's no connection for them. This spinning is
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China hidden from the user-land code, but it's there nonetheless.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China This can result in the same load-spiking wasteful behaviour
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China that a non-blocking solution to the multiple sockets case
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>For this reason we have found that many architectures behave
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China more "nicely" if we serialize even the single socket case. So
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China this is actually the default in almost all cases. Crude
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China experiments under Linux (2.0.30 on a dual Pentium pro 166
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China w/128Mb RAM) have shown that the serialization of the single
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China socket case causes less than a 3% decrease in requests per
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China second over unserialized single-socket. But unserialized
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China single-socket showed an extra 100ms latency on each request.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China This latency is probably a wash on long haul lines, and only an
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China issue on LANs. If you want to override the single socket
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China serialization you can define
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>SINGLE_LISTEN_UNSERIALIZED_ACCEPT</code> and then
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China single-socket servers will not serialize at all.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h4>Lingering Close</h4>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>As discussed in <a
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China href="http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt">
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China draft-ietf-http-connection-00.txt</a> section 8, in order for
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China an HTTP server to <strong>reliably</strong> implement the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China protocol it needs to shutdown each direction of the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China communication independently (recall that a TCP connection is
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China bi-directional, each half is independent of the other). This
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China fact is often overlooked by other servers, but is correctly
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China implemented in Apache as of 1.2.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>When this feature was added to Apache it caused a flurry of
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China problems on various versions of Unix because of a
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China shortsightedness. The TCP specification does not state that the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China FIN_WAIT_2 state has a timeout, but it doesn't prohibit it. On
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China systems without the timeout, Apache 1.2 induces many sockets
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China stuck forever in the FIN_WAIT_2 state. In many cases this can
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China be avoided by simply upgrading to the latest TCP/IP patches
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China supplied by the vendor. In cases where the vendor has never
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China released patches (<em>i.e.</em>, SunOS4 -- although folks with
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China a source license can patch it themselves) we have decided to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China disable this feature.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>There are two ways of accomplishing this. One is the socket
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China option <code>SO_LINGER</code>. But as fate would have it, this
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China has never been implemented properly in most TCP/IP stacks. Even
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China on those stacks with a proper implementation (<em>i.e.</em>,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China Linux 2.0.31) this method proves to be more expensive (cputime)
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China than the next solution.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>For the most part, Apache implements this in a function
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China called <code>lingering_close</code> (in
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>http_main.c</code>). The function looks roughly like
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China void lingering_close (int s)
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China char junk_buffer[2048];
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China /* shutdown the sending side */
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China shutdown (s, 1);
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China signal (SIGALRM, lingering_death);
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China select (s for reading, 2 second timeout);
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China if (error) break;
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China if (s is ready for reading) {
c0c934808d1b7d058148814255f32064a0e09555lin wang - Sun Microsystems - Beijing China if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China /* just toss away whatever is here */
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China This naturally adds some expense at the end of a connection,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China but it is required for a reliable implementation. As HTTP/1.1
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China becomes more prevalent, and all connections are persistent,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China this expense will be amortized over more requests. If you want
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China to play with fire and disable this feature you can define
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>NO_LINGCLOSE</code>, but this is not recommended at all.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China In particular, as HTTP/1.1 pipelined persistent connections
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China come into use <code>lingering_close</code> is an absolute
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China necessity (and <a
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China href="http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html">
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China pipelined connections are faster</a>, so you want to support
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h4>Scoreboard File</h4>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Apache's parent and children communicate with each other
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China through something called the scoreboard. Ideally this should be
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China implemented in shared memory. For those operating systems that
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China we either have access to, or have been given detailed ports
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China for, it typically is implemented using shared memory. The rest
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China default to using an on-disk file. The on-disk file is not only
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China slow, but it is unreliable (and less featured). Peruse the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>src/main/conf.h</code> file for your architecture and
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China look for either <code>USE_MMAP_SCOREBOARD</code> or
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>USE_SHMGET_SCOREBOARD</code>. Defining one of those two
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China (as well as their companions <code>HAVE_MMAP</code> and
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>HAVE_SHMGET</code> respectively) enables the supplied
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China shared memory code. If your system has another type of shared
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China memory, edit the file <code>src/main/http_main.c</code> and add
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China the hooks necessary to use it in Apache. (Send us back a patch
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China too please.)</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Historical note: The Linux port of Apache didn't start to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China use shared memory until version 1.2 of Apache. This oversight
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China resulted in really poor and unreliable behaviour of earlier
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China versions of Apache on Linux.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h4><code>DYNAMIC_MODULE_LIMIT</code></h4>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>If you have no intention of using dynamically loaded modules
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China (you probably don't if you're reading this and tuning your
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China server for every last ounce of performance) then you should add
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <code>-DDYNAMIC_MODULE_LIMIT=0</code> when building your
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China server. This will save RAM that's allocated only for supporting
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China dynamically loaded modules.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <h3><a id="trace" name="trace">Appendix: Detailed Analysis of a
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Here is a system call trace of Apache 2.0.38 with the worker MPM
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China on Solaris 8. This trace was collected using:</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<code>truss -l -p <i>httpd_child_pid</i></code>.</code>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>The <code>-l</code> option tells truss to log the ID of the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China LWP (lightweight process--Solaris's form of kernel-level thread)
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China that invokes each system call.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>Other systems may have different system call tracing utilities
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China such as <code>strace</code>, <code>ktrace</code>, or <code>par</code>.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China They all produce similar output.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China <p>In this trace, a client has requested a 10KB static file
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China from the httpd. Traces of non-static requests or requests
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China with content negotiation look wildly different (and quite ugly
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/67: accept(3, 0x00200BEC, 0x00200C0C, 1) (sleeping...)
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/67: accept(3, 0x00200BEC, 0x00200C0C, 1) = 9
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<p>In this trace, the listener thread is running within LWP #67.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<p>Note the lack of accept(2) serialization. On this particular
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinaplatform, the worker MPM uses an unserialized accept by default
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinaunless it is listening on multiple ports.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: lwp_park(0x00000000, 0) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/67: lwp_unpark(65, 1) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<p>Upon accepting the connection, the listener thread wakes up
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinaa worker thread to do the request processing. In this trace,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinathe worker thread that handles the request is mapped to LWP #65.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: getsockname(9, 0x00200BA4, 0x00200BC4, 1) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<p>In order to implement virtual hosts, Apache needs to know
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinathe local socket address used to accept the connection. It
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinais possible to eliminate this call in many situations (such
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinaas when there are no virtual hosts, or when <code>Listen</code>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinadirectives are used which do not have wildcard addresses). But
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinano effort has yet been made to do these optimizations. </p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: brk(0x002170E8) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: brk(0x002190E8) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<p>The brk(2) calls allocate memory from the heap. It is rare
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinato see these in a system call trace, because the httpd uses
3ae945c326c1fc078149f2c8b11fac0cc8f6d1d6lin wang - Sun Microsystems - Beijing Chinacustom memory allocators (<code>apr_pool</code> and
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<code>apr_bucket_alloc</code>) for most request processing.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing ChinaIn this trace, the httpd has just been started, so it must
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinacall malloc(3) to get the blocks of raw memory with which
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinato create the custom memory allocators.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: fcntl(9, F_GETFL, 0x00000000) = 2
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: fstat64(9, 0xFAF7B818) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B910, 2190656) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: fstat64(9, 0xFAF7B818) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B914, 2190656) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: setsockopt(9, 65535, 8192, 0xFAF7B918, 4, 2190656) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: fcntl(9, F_SETFL, 0x00000082) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<p>Next, the worker thread puts the connection to the client (file
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinadescriptor 9) in non-blocking mode. The setsockopt(2) and getsockopt(2)
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinacalls are a side-effect of how Solaris's libc handles fcntl(2) on sockets.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: read(9, " G E T / 1 0 k . h t m".., 8000) = 97
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<p>The worker thread reads the request from the client.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: stat("/var/httpd/apache/httpd-8999/htdocs/10k.html", 0xFAF7B978) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: open("/var/httpd/apache/httpd-8999/htdocs/10k.html", O_RDONLY) = 10
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<p>This httpd has been configured with <code>Options FollowSymLinks</code>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinaand <code>AllowOverride None</code>. Thus it doesn't need to lstat(2)
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinaeach directory in the path leading up to the requested file, nor
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinacheck for <code>.htaccess</code> files. It simply calls stat(2) to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinaverify that the file: 1) exists, and 2) is a regular file, not a
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C) = 10269
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<p>In this example, the httpd is able to send the HTTP response
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinaheader and the requested file with a single sendfilev(2) system call.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing ChinaSendfile semantics vary among operating systems. On some other
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinasystems, it is necessary to do a write(2) or writev(2) call to
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinasend the headers before calling sendfile(2).</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: write(4, " 1 2 7 . 0 . 0 . 1 - ".., 78) = 78
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<p>This write(2) call records the request in the access log.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing ChinaNote that one thing missing from this trace is a time(2) call.
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing ChinaUnlike Apache 1.3, Apache 2.0 uses gettimeofday(3) to look up
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinathe time. On some operating systems, like Linux or Solaris,
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinagettimeofday has an optimized implementation that doesn't require
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinaas much overhead as a typical system call.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: shutdown(9, 1, 1) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: poll(0xFAF7B980, 1, 2000) = 1
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: read(9, 0xFAF7BC20, 512) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: close(9) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<p>The worker thread does a lingering close of the connection.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: close(10) = 0
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/65: lwp_park(0x00000000, 0) (sleeping...)
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<p>Finally the worker thread closes the file that it has just delivered
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinaand blocks until the listener assigns it another connection.</p>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China/67: accept(3, 0x001FEB74, 0x001FEB94, 1) (sleeping...)</pre>
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing China<p>Meanwhile, the listener thread is able to accept another connection
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinaas soon as it has dispatched this connection to a worker thread (subject
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinato some flow-control logic in the worker MPM that throttles the listener
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinaif all the available workers are busy). Though it isn't apparent from
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinathis trace, the next accept(2) can (and usually does, under high load
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinaconditions) occur in parallel with the worker thread's handling of the
dd1de3740722a4b99a74005255effebbd20a6d70lin wang - Sun Microsystems - Beijing Chinajust-accepted connection.</p>