Squeezing the most performance out of your Apache server
can make difference in how your Web site functions and the impression it makes.
Even fractions of a second matter, especially on dynamic sites. This article
looks primarily at configuration and installation, two areas where you have the
most control.
Measuring and Improving Apache Server Performance:
Apache was designed to be as fast as possible. It's easy,
with a fairly low-powered machine, to completely saturate a low-end Internet
link with little effort. However, as sites become more complex and the
bandwidth needs of different connection types increase, getting the best
performance out of an Apache installation and Web sites becomes more important.
Enhancing performance means nothing if the changes
achieved are only minor gains. Spending hours or even days finely tuning a
server for just a few percentage points is a waste of time. The first step,
therefore, is to determine how fast the server is running and its general
performance level so you can work out how to improve performance and measure
the changes.
This is not the first time we've discussed Apache testing
(see Staying Out of Deep Water: Performance Testing Using HTTPD-Test's Flood).
As was noted previously, determining which parts of your Web application are
causing the problem — particularly identifying whether it's Apache or the
application environment you are using with dynamic sites — can be difficult.
Identifying problems in dynamic applications is beyond the scope of this
article, but we will look at ways to generally improve the speed of Apache and
how it interacts with other components to support a Web site.
Apache Server Host Hardware
The machine and operating system environment on which
Apache is running have the most effect. Obviously, an old 386-based PC will not
have the same performance as a new P4 or dual-processor model, but you can make
other improvements. Avoiding, for the moment, hardware changes, the biggest
thing you can do is ensure Apache is running on a dedicated server. Coexistence
with other applications will affect Web server performance.
In most situations, but particularly with static sites,
the amount of RAM is a critical factor because it will affect how much
information Apache can cache. The more information that can be cached, the less
Apache has to rely on the comparatively slow process of opening and reading
from a file on disk. If the site relies mostly on static files, consider using
the mod_cache; if plenty of RAM is available, consider mod_mem_cache.
The former caches information to disk, which makes a
significant difference if the site relies on mod_include to build up a page as
it caches the final version. With mod_mem_cache, the information is stored in
the memory heap shared by all the Apache processes.
Using a fast disk or, better still, a Redundant Array of
Inexpensive Disks (RAID) solution in one of the striping modes (e.g.,RAID 0,
0+1, 5, 10, or 50) will improve the overall speed of access to files served.
Note, however, if you do go down any of these routes, a
hardware, rather than software solution is the best option.
Finally, in terms of hardware, CPU power can have an
impact on dynamic sites with the additional overhead of executing an
application for each page accessed. Heavily dynamic pages have a higher CPU
requirement.
Apache Server Host Environment
Regardless of operating system, the following
optimization principles apply:
• Keep
other background applications to a minimum. If you are really serious about
performance, this should even include some background processes that some would
consider vital. For example, in Unix, switch off NFS, any printing services,
and even sendmail if it's not needed. Under Windows, use the System control
panel to optimize the system for applications and system cache, and optimize
the system for performance. Make sure, of course, any required applications or
services, like MySQL are still running.
• Avoid
using the system. If you start compiling applications, editing files, or
otherwise employing the machine, you'll reduce its Web serving performance. If
you must edit components or install software, build or edit the components on
another machine and copy them over.
• Keep
your system up to date. Although a good idea just from a security point of
view, software patches and updates can make significant improvements to network
and I/O performance.
The Apache Server Application
Then, of course, there is the Apache application itself.
First, ensure it is built correctly with only the modules
and extensions required for your Web sites. This means, for example, you can
ignore the rewriting module if it's not required. The main benefit of this is a
reduction in memory overhead, but a very good side benefit is that you can't
accidentally enable these options and therefore reduce server performance.
Static vs. Dynamic
Flexibility is the primary concern of most Apache
administrators, but flexibility has a cost. Using Dynamically loaded modules
within Apache is a convenience, but using them can result in a performance hit,
as the code is loaded when the module is required. Dynamic modules also have
the advantage of helping keep memory requirements down.
To build in static mode, use the configure script and
specify the modules you want, but don't specify them as shared (e.g., use
--enable-rewrite not --enable-rewrite=shared, or use the shared option
--enable-so.
Module Configuration
If you are using a static configuration of Apache, choose
the modules you wish to incorporate with care. Using static mode comes at a
price — the more modules, the more memory you use. Thus, a forked multi-processing
module can have a significant effect on the machine's memory requirements.
Note that some items are automatically included, so
you'll need to explicitly enable and disable needed modules. Also remember to
include any third-party modules (e.g., authentication, PHP, or mod_perl), the
Web service requires. Use configure --help to get a list of the available
options.
Apache Server Configuration
Once your environment is set up and your Apache
application optimized, it's time to start looking at the configuration file for
further optimization tricks. A good way to start is by simply cleaning up the
file so directives are limited to a few hundred, which is achieved by simply
removing the comments. Beyond this, it becomes a case of removing unnecessary elements
or those that fail to provide any appreciable benefit.
Simplifying the Configuration File
The first step to optimization should be the
simplification of the configuration file. It will not have any direct
improvement on performance, but it will make the configuration file easier to
use and therefore make you less likely to miss a directive or component that
needs modifying.
If you are doing any kind of optimization, start with one
of the default-supplied configuration files. They are usually available in the
Apache configuration directory as httpd.conf.orig or httpd-std.conf. Don't be
tempted to use the high performance-std.conf file; in the long term it's not
really as useful as you would think once you start adding vast quantities of
additional configuration information. On the other hand, if a very fast static
Web server is the goal, this is probably the easiest way to get things up and
running.
If you know your Apache configuration directives, or are
willing to look at the documentation, the quickest and most effective step is
to remove all comments from the configuration file, as they often detract from
the actual directives. You can also remove references to MPM systems not in use
on the chosen platform.
Disabling Components and Systems
Now that we've got a trimmed-back and simplified
configuration file, we can start removing the configuration elements for the
systems not in use. In particular:
• HostnameLookups
add overhead to each request by requesting DNS lookup on the client, first
reverse to find the name from the IP address, and then a forward look up to
ensure information is not spoofed. In most cases, you can simply disable this.
If you regularly process your logs, use post-processing to determine the
information. To disable lookups, include the following directive
HostnameLookups off.
• Symbolic
links, when enabled, will ensure Apache checks every request to see if a
symbolic link is involved in the request. There will be one call to the lstat()
system call for each directory to which the request relates. Unless you have a
need for symbolic links, switch it off by using: Options
-FollowSymLinks
• Server
status and info, although very useful when testing and monitoring your server,
create additional overhead for the Web server. Disable it by looking for any
SetHandler server-status directives, and, if possible, remove the module from
Apache when you configure the application during build.
• Wildcards
and flexible options should generally be avoided if you can be more explicit.
For example, the DirectoryIndex directive, explicitly specifies the list of
files to be configured, always listing the most likely choice first.
• CGI
execution should take place unless you have good reason for not doing so. Put
all CGI files into a single directory and configure it for CGI execution. This
prevents Apache from trying to determine whether a request is actually for a
CGI component or a static file.
Disable Logs
Writing log information is a time consuming process.
Although Apache keeps the log files open so that it's just a case of writing
the information, this can take up valuable time. If storing log information is
not required, you can save a few processor cycles by disabling it. To do this,
simply comment out the log lines in the configuration file.
If you do decide to keep your logs, disable
HostnameLookups (see above) and make sure you copy the log information on to
another machine to parse the file for analysis.
Simplify Directory-level Configurations
The .htaccess files are an incredibly useful way of
extending the configurable parameters of your Apache server without having to
edit the main configuration file each time you want to change something. The
problem is that the use of .htaccess files also slows down the server.
First, it has to look to see if a .htaccess file exists,
then it has to parse and process the elements before finally applying the
configuration to the directory in question. Worse still, Apache must determine
this information not only for the current directory, but also for any parent
directories and it then must make the changes based on the contents of all
these files.
If you want maximum performance however, you should
disable the use of .htaccess files altogether. Any directory specific
configuration can go in the main configuration file where it can be parsed once
by Apache when the server starts.
To disable .htaccess add the directive AllowOverride None
to any section.
The Multi-Processing Module (MPM) is what enables a
specific platform to handle multiple concurrent connections. MPM modules are
platform specific. Solutions are available to work specifically with Unix,
Windows, BeOS, and NetWare. For some platforms more than one alternative is available.
For most users, the default configuration for a particular environment works
fine, especially when getting the exact parameters correct can be a
time-consuming task in and of itself. By comparison, many of the techniques
already described may yield better performance, but when you want to squeeze
the maximum performance out of your server, you must adjust the configuration.
Under most platforms only MPM is available, under Unix
there are two options, prefork and worker. The prefork MPM forks off a number
of identical Apache processes, while the worker creates multiple threads. In
general, prefork is better on systems with one or two processors where the
operating systems is better geared toward time slicing between multiple
processes. On a system with a higher number of CPUs the threading model will
probably be more effective.
In nearly all cases, the MaxClients directive is the most
effective for increasing server performance, as it controls that maximum number
of simultaneous connections Apache can handle.
Optimizing Static Components
If your Web site uses a lot of static components, or if
you've split the static and dynamic elements across two or more Web servers,
then your main goal should be to improve the response time for Apache sending
back the information that was requested. The easiest way to do this is to use
the mod_cache module. You can use this with the mod_disk_cache and
mod_mem_cache to provide disk-based and memory-based caches of the static
files.
Check out the Apache documentation on the mod_cache
module for more information.
Optimizing Dynamic Components
Dynamic components are probably the most time-sapping
component of any Web server. Dynamic components, especially if you are using
CGI, can add seconds to the response time just to load and execute a simple
application. A more system options can be found at mod_perl, PHP, and Python,
and the Jakarta interface for Java.
The main advantage of the script-based solutions is that
they embed the interpreter into the Apache executable, which removes the
initial loading problem with dynamic scripts. Some will even cache the parsed
script so the next time it's requested it need only to be executed.
Configuration can be complex and getting the exact system
correct can be time consuming. Some solutions also don't work quite as one
would expect with virtual hosts, and you will need to change certain scripts to
take full advantage of the speed enhancements on offer.
The improvements, however, can be significant, with as
much as 70 percent of the execution time being knocked off of a Perl script
simply by using mod_perl in place of CGI. With even more work, these solutions
also allow you to keep persistent connections open to databases or to cache
information between requests. This is great for e-commerce sites and also for
reducing the overhead of otherwise loading information between requests.
Summary
Although Apache is highly configurable and a relatively
complex application, it's interesting to note that standard installations of
Apache actually achieve very high levels of performance. One area where you can
easily and significantly improve performance is by tuning parameters.
Unfortunately, often the components you have least control over within Apache —
dynamic elements and CGI scripts, for example — are the ones that have the
biggest impact on performance. Monitor a typical Apache server and you'll see
that the time taken for Apache to answer a connection and send data back is in
the range of milliseconds — but waiting for the source of that data can take
seconds.
This is not to say the optimizations we've highlighted
are pointless, however. During the course of a day these saved milliseconds add
up. More significant though is that cleaning up and simplifying your Apache
configuration will do more to reduce the administration overhead than any time
you might save when serving information.
