Impossible tri-bar

Digital Phenomena - Your first stop for internet consultancy 
Tuning Apache Web Servers for Speed

Page 3 — Run-Time Configuration Issues

HostnameLookups

Prior to Apache 1.3, HostnameLookups defaulted to On. This adds latency to every request because it requires a DNS lookup to finish before the request is completed. In Apache 1.3, this setting defaults to Off. However (in 1.3 or later), if you use any allow from domain or deny from domain directives, then you will pay for a double-reverse DNS lookup (a reverse, followed by a forward to make sure that the reverse is not being spoofed). So for the highest performance, avoid using these directives (though it's fine to use IP addresses rather than domain names).

Note that it's possible to scope the directives, such as within a <Location /server-status> section. In this case, the DNS lookups are only performed on requests matching the criteria. Here's an example that disables lookups except for .html and .cgi files:

     
    
    HostnameLookups off 
    <Files ~ "\.(html|cgi)$> 
         HostnameLookups on 
    </Files> 
But even still, if you just need DNS names in some CGIs, you could consider doing the gethostbyname call in the specific CGIs that need it.

FollowSymLinks and SymLinksIfOwnerMatch

Wherever in your URL-space you do not have an Options FollowSymLinks or you do have an Options SymLinksIfOwnerMatch, Apache will have to issue extra system calls to check up on symlinks - one extra call per filename component. For example, if you have

     DocumentRoot /www/htdocs 
    <Directory /> 
        Options SymLinksIfOwnerMatch 
    </Directory> 
and a request is made for the URI /index.html, then Apache will perform lstat(2) on /www, /www/htdocs, and /www/htdocs/index.html. The results of these lstats are never cached, so they will occur on every single request. If you really desire the symlinks security checking, you can do something like this:
     DocumentRoot /www/htdocs 
    <Directory /> 
        Options FollowSymLinks 
    </Directory> 
    <Directory /www/htdocs> 
        Options -FollowSymLinks +SymLinksIfOwnerMatch 
    </Directory> 
This at least avoids the extra checks for the DocumentRoot path. Note that you'll need to add similar sections if you have any Alias or RewriteRule paths outside of your document root. For highest performance, and no symlink protection, set FollowSymLinks everywhere, and never set SymLinksIfOwnerMatch.

AllowOverride

Wherever in your URL-space you allow overrides (typically .htaccess files), Apache will attempt to open .htaccess for each filename component. For example, if you have

     DocumentRoot /www/htdocs 
    <Directory /> 
        AllowOverride all 
    </Directory> 
and a request is made for the URI /index.html. Then Apache will attempt to open /.htaccess, /www/.htaccess, and /www/htdocs/.htaccess. The solutions are similar to the previous case of Options FollowSymLinks. For highest performance use AllowOverride None everywhere in your filesystem.

Negotiation

If at all possible, avoid content negotiation if you're really interested in every last ounce of performance. In practice, the benefits of negotiation outweigh the performance penalties. There is one case where you can speed up the server. Instead of using a wildcard such as

    DirectoryIndex index
use a complete list of options:
     DirectoryIndex index.cgi index.pl index.shtml index.html 
where you list the most common choice first.

Process Creation

Prior to Apache 1.3, the MinSpareServers, MaxSpareServers, and StartServers settings all had drastic effects on benchmark results. In particular, Apache required a "ramp-up" period in order to reach a number of children sufficient to serve the load being applied. After the initial spawning of StartServers children, only one child per second would be created to satisfy the MinSpareServers setting. So a server being accessed by 100 simultaneous clients using the default StartServers of 5, would take around 95 seconds to spawn enough children to handle the load. This works fine in practice on real-life servers, because they aren't restarted frequently; but it reflects really poorly on benchmarks that might run for only 10 minutes.

The one-per-second rule was implemented in an effort to avoid swamping the machine with the startup of new children. If the machine is busy spawning children, it can't service requests. But it has such a drastic effect on the perceived performance of Apache that the rule had to be replaced. As of Apache 1.3, the code will relax the one-per-second rule. It will spawn one, wait a second, then spawn two, wait a second, then spawn four, and it will continue exponentially until it is spawning 32 children per second. It will stop whenever it satisfies the MinSpareServers setting.

This appears to be responsive enough that it's almost unnecessary to twiddle the MinSpareServers, MaxSpareServers, and StartServers knobs. When more than four children are spawned per second, a message will be emitted to the ErrorLog. If you see a lot of these errors, then consider tuning these settings. Use the mod_status output as a guide.

Related to process creation is process death induced by the MaxRequestsPerChild setting. By default this is set to 30, which is probably far too low unless your server is using a module such as mod_perl, which causes children to have bloated memory images. If your server is serving mostly static pages, then consider raising this value to something like 10,000. The code is robust enough that this shouldn't be a problem.

When keep-alives are in use, children will be kept busy doing nothing, waiting for more requests on the already-open connection. The default KeepAliveTimeout of 15 seconds attempts to minimize this effect. The trade-off here is between network bandwidth and server resources. In no event should you raise this above about 60 seconds, as most of the benefits are lost.

next page»


|Home|About Us|Services|Search|
|Software|Products|Support|Links|Latest|
W3C validatedW3C validated CSSCompatible with all browsers