Selected "Tips from the Author" of an O'Reilly web tuning book( http://web.oreilly.com/news/webperf_1098.html )

• Make sure reverse DNS lookups are turned off in your web server. Reverse DNS maps IP numbers to machine names in the web servers logs and in CGI programs. CGI's can do the lookup themselves if they need to and you can use log analysis programs to fill in names in the log files later. Reverse DNS just slows you down if you do it for each request.

• Look for excessive TCP retransmits. Turn up the TCP retransmit timeout if needed. Many servers are tuned for the very small latencies of a LAN and so perform poorly on the Internet.

• Use the trailing slash when requesting a directory, eg: http://www.oreilly.com/catalog/ . Otherwise the server will just reply to the brower with a message that it should use a trailing slash and your browser will then re-issue the request in the formally correct way. Things will work without the slash, but they'll be slightly quicker with it. ( MattWalsh: wonder how Web Bench & Rain Bench handle this... )

Selected highlights from Gaudet's often quoted article ( http://ins01.med.upenn.edu/manual/misc/perf-tuning.html )

Runtime Settings

• The single biggest hardware issue affecting webserver performance is RAM. A webserver should never ever have to swap, swapping increases the latency of each request beyond a point that users consider "fast enough". This causes users to hit stop and reload, further increasing the load.

• You can, and should, control the MaxClients setting so that your server does not spawn so many children it starts swapping.

• Apply the latest vendor TCP/IP patches.

• Prior to Apache 1.3, HostnameLookups defaulted to On. This adds latency to every request because it requires a DNS lookup to complete before the request is finished. In Apache 1.3 this setting defaults to Off. However (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 (it's fine to use IP addresses rather than domain names).

• 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.

• Wherever in your URL-space you allow overrides (typically .htaccess files) Apache will attempt to open .htaccess for each filename component. For highest performance use AllowOverride None everywhere in your filesystem.

• 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 on the order 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 does really poorly on benchmarks which might only run for ten 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 it 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 4 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 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 10000. 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 tradeoff 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.

Compile Settings

• If you include mod_status and you also set ExtendedStatus On when building and running Apache, then on every request Apache will perform two calls to gettimeofday(2). This is all done so that the status report contains timing indications. For highest performance, set ExtendedStatus off (which is the default).

• Apache's parent and children communicate with each other through something called the scoreboard. Ideally this should be implemented in shared memory. For those operating systems that we either have access to, or have been given detailed ports for, it typically is implemented using shared memory. The rest default to using an on-disk file. The on-disk file is not only slow, but it is unreliable (and less featured). Peruse the src/main/conf.h file for your architecture and look for either USE_MMAP_SCOREBOARD or USE_SHMGET_SCOREBOARD. Defining one of those two (as well as their companions HAVE_MMAP and HAVE_SHMGET respectively) enables the supplied shared memory code. If your system has another type of shared memory, edit the file src/main/http_main.c and add the hooks necessary to use it in Apache. (Send us back a patch too please.)

-- MattWalsh - 15 Sep 2000

http://www.kegel.com/mindcraft_redux.html

(credit goes to JC for finding this one)

-- AdamPowers - 20 Nov 2000

• SGI Web Performance Tuning Guide: http://www.sgi.com/tech/web/
• SGI Accellerating Apache: Accelerating Apache http://oss.sgi.com/projects/apache/ (patches etc)
• Dan Kegel on Linux and Apache tuning: http://www.kegel.com/mindcraft_redux.html

-- MattWalsh - 31 Jan 2002