Website Performance: Taxonomy of Tips introduced a classification scheme to help us organize the many performance tips found on the Internet. Today’s article reviews the tips in the third category, the-server-processes-the-request. Server-side scripting and services accessed by it (e.g., databases) will be reviewed in future articles. Today we look at the web server and its environment.
The Web Server’s Environment
Web server software (e.g., Apache, IIS) runs on a computer and accesses a network. This is its environment. If its environment is slow, the web server is slow. If the environment doesn’t provide resources when they are needed, the web server is slow. It the network connection is slow, the web server is slow. If the hardware and operating system aren’t designed and configured for high performance, especially high performance networking, the web server is slow.
If the web server’s computer runs any other program, the web server competes with that other program for system resources. If the other program uses too many resources, the web server suffers the consequences. The solution, of course, is to run the web server on a dedicated machine. Even services used by the web server (e.g., a database management system) should be installed on other machines and accessed through a high-speed network.
A web server should never swap memory to disk, so more memory is always a good idea. Go ahead and max out.
High-speed hard disks are also mandatory. Built-in, hardware-based caching is essential. Distributing the load across multiple disks is a good idea, but it requires some thought. Distributing the load is different from distributing the files because some files are used more often than others.
If the hardware is not designed for high-speed applications, especially high-speed networking, the web server software never achieves high speeds. A system is as fast as its slowest component, so clock speed, bus width, internal caching, HDD bus type (e.g., SCSI, EIDE), network cards, and other performance-critical concepts must be carefully considered. Do not expect to find what we need amongst lower-priced machines.
Server machine configuration is important, too. The operating system must be finely-tuned to supply and manage available resources. Bandwidth caps, for example, can negatively impact server performance.
We cannot skimp on the Internet service, either. A typical off-the-shelf service designed for web browsing restricts outgoing bandwidth so it can increase incoming bandwidth, exactly the opposite of what a web server needs. Since servers receive small requests and send back larger responses, much of the incoming bandwidth will never be used. Purchase a service with a large outgoing/incoming bandwidth ratio.
DSL and cable connections may provide enough bandwidth for small websites, but they are bottlenecks for larger sites. Look at other options.
Networks should be tuned for performance, especially to minimize packet loss and retransmission rates. Packets are dropped when the number of connection requests exceeds the number of connections. When this happens, the browser has to send the request to the server a second (or perhaps third) time.
Web Server Configuration
Having created a lightning-fast environment for our server, let’s turn our attention to the web server software itself. Apache and Microsoft supply tips for their products, but many of these tips (with appropriate changes) apply to other web servers, too.
Apache gives us the following tips for configuring its web server:
- at compile time:
- Choose an appropriate MPM (multi-processing module).
- Eliminate modules you don’t use.
- Use the –enable-nonportable-atomics switch if your hardware allows it.
- Set ExtendedStatus off (which is the default).
- Run servers without multiple Listen statements if you want the highest performance, but… (read the doc)
- Implement the scoreboard in shared memory, not on disk.
- Set -DDYNAMIC_MODULE_LIMIT=0 and don’t use dynamically loaded modules.
- Control the MaxClients setting so that your server does not spawn so many children that it starts swapping.
- Turn HostnameLookups off to avoid reverse DNS lookups for every request.
- Allow or Deny should use IP addresses rather than domain names (if possible).
- Avoid symlinks security checking if you can. Configure it correctly if you can’t.
- Use AllowOverrideNone.
- Specify a complete list of options with DirectoryIndex (e.g., “DirectoryIndex index.cgi index.pl index.shtml index.html” instead of “DirectoryIndex index”) where you list the most common choice first.
- Explicitly create a type-map file rather than using MultiViews.
- Depending on your platform, turn memory mapping on or off.
- Depending on your platform, turn sendfile on or off.
- When more than 4 children are spawned per second, a message is sent to the ErrorLog. If you get a lot of these errors, tune MinSpareServers, MaxSpareServers, and StartServers.
- Set MaxRequestsPerChild appropriately.
- Adjust KeepAliveTimeout to match your production server’s experience.
Please consult the original document for the details.
Microsoft also gives us tips for configuring its web server:
- Log only essential information or completely disable logging.
- Disable ASP debugging in production environments.
- Tune the value of the ASP Threads Per Processor Limit property.
- Tune the value of the ASP Queue Length property.
- Tune the MaxPoolThreads registry entry.
- Disable WCF services tracing.
- Configure ASP.NET MaxConcurrentRequests for IIS 7.5/7.0 Integrated mode.
- Enable HTTP compression.
Please consult the original document for the details.
Here are a few tips found in various places around the web (see the references at the bottom of this article):
- Disable reverse DNS lookups.
- Disable logging (or keep it to a bare minimum).
- Disable unused plugins, modules, options, features, etc.
- Have the server automatically specify a character set in HTTP headers.
- Limit the application pool queue length.
- Periodically restart worker processes.
- Recycle application pools.
The last few tips come to us courtesy of Mikayel Vardanyan’s IIS performance tips article, a must-read if you use IIS.
Web Server Usage
Consider all resources as precious (disregard opinions that say it doesn’t matter). Don’t let any process treat any resource as a commodity. Fix programs that spawn a large number of processes, don’t release connections, etc. Add more memory if you must, but it’s better to locate and fix the code that causes the problem.
Web-Server Monitoring
Because of the dynamic nature of the Internet, what performs well today may not perform well tomorrow. Not surprisingly, continual monitoring is essential. The Paid Monitor cloud-based monitoring system not only keeps an eye on our website, but also notifies us when measurements go outside the bounds we set.
Application performance monitoring and system performance monitoring are both important. The Application Performance Monitoring Primer (part one, part two, and part three) talks about monitoring from the end-user’s viewpoint. See Monitoring WMI Data With VbScript for information about monitoring system performance data in Windows. See Custom Monitors in Paid Monitor with Python and M3 – Paid Monitor Monitor Manager for information about monitoring the output of command-line tools, which is a handy way to monitor Unix system performance.
References
Apache Performance Tuning. Published by Apache Software Foundation at httpd.apache.org/docs/2.2/misc/perf-tuning.html. Accessed 2012.01.31.
The Application Performance Monitoring Primerby Warren Gaebel.
