an Optimized Apache 1.3 for AIX:
These steps assume AIX 4.3.3 or better, Apache 1.3.23 or better,
as well as the VisualAge C++ 5.0 compilers. They cover installation
of the web server itself, and nothing else. There are optimizations
to be had with mod_ssl but these are relatively obvious (use
the MM library to cache SSL state in RAM).
One of the major points in this document is: have enough RAM.
Memory is cheap, and a web server should never have to swap.
Unused RAM goes towards file caching (adjustable via vmtune),
so it's a win-win situation.
First, create an unprivileged user and group
for the web server to run as. Running your web server as root
is never a good idea. This account should not be able to log
into the machine, though sometimes for management it is useful
to su to the account from another account. In this case, setting
a random password for the account but forgetting it,
and using sudo to switch users is a good option. This isn't
specifically a performance optimization, but if your web server
is broken into then your performance isn't going to be very
Ensure that the user you specify is able to start as many processes as
it needs. You don't want your web server hitting an OS limit of 256 processes
(manage that at the web server level, not the OS level). You can check
this at the OS level by viewing the maxuproc setting: lsattr
-E -l sys0
Decide whether you are going to need more than
256 httpd processes. This is a hard limit imposed by Apache.
If you think you need more than 256 you should edit src/include/httpd.h
and change HARD_SERVER_LIMIT. You will need to ensure that
your machine has enough RAM to handle this.
- Decide where your installation will reside. The default location
for Apache is /usr/local/apache. However, if performance is an
issue you should put your content on one set of drives and the
logs on another. Logging is very disk-intensive and will hinder
the performance of the web server if there is contention between
log writes and content reads.
If you have two disks, a fast one and a slow one, use the fast one for the
logs and the slow one for the content. Why? With enough RAM the operating
system will cache the content (static pages and the CGI files themselves),
but writes still need to be flushed to disk rapidly. And later, if you are
analyzing the logs you'll probably want the extra speed on the logging disks.
Also remember that your operating system needs to do things, so using disks
that are separate from the OS is a good idea, too.
You can adjust the amount of RAM dedicated to the OS's file cache using vmtune.
A discussion of this is present in our notes
on tuning AIX.
- Figure out what architecture your machine is. In this example,
I'm tuning for an IBM RS/6000 7025-F50, which has PowerPC 604
CPUs in it. IBM maintains a procedure on
how to deduce this information, and a copy is mirrored locally.
- Configure Apache, specifying the location you want to install
it as the prefix (our suggestion is just to use /usr/local/apache,
but mount the appropriate filesystems there). Adjust the -qarch
and -qtune flags according to the architecture of your machine.
Information and parameters for those flags can be found in the
VisualAge C++ documentation.
env CC=cc CFLAGS="-O3
-qstrict -qarch=ppc -qtune=604" ./configure --enable-module=most
- Install Apache (make install).
- Edit httpd.conf. Here are some thoughts on certain settings:
Start the web server and watch it. Using the server-status
handler and good old 'ps' you can watch to see what Apache is
doing. You can also begin to use 'ab', which ships with Apache,
to benchmark the server. It helps if you benchmark the server
from another, preferably faster machine.
- KeepAlives: the KeepAlive and MaxKeepAliveRequests parameters
should be on, and set high. KeepAlives allow a client to request
multiple files with the same connection to the web server.
These persistent connections will often yield a significant
performance boost for HTML pages with graphics, as the client
does not need to create a connection to the server for each
graphic it wants to retrieve. Conversely, MaxKeepAliveRequests puts
a limit on how many files can be retrieved via a single connection,
so one client cannot hog resources on the server. The defaults
should be fine in most cases.
- Spare Servers: the MinSpareServers,
and MaxClients parameters
should be set to reasonable values for the load. Apache forks
off a process for each client, and under load will start
spawning more copies of itself to handle the load. By having
some spare httpd processes around the server can avoid the
work needed to fork new copies. If you set these settings
too high, your machine may waste RAM on extra, unneeded processes.
If you set them too low, your server will work hard to spawn
new processes to deal with load.
At startup, Apache spawns the number of processes specified in StartServers.
It then routinely checks to make sure that the number of servers running
is between the min and max. Obviously, your StartServers parameter
should be set between the min and max, then.
a brake to stop Apache from overwhelming the server. MaxSpareServers is
just a setting to govern how many extra copies of httpd stick
around. If Apache is under heavy load, it will spawn as many
copies of itself as necessary, up to MaxClients or
the hard server limit in httpd.h, to deal with the load.
This may cause the machine to run out of RAM or do other
bad things, and the clients will start to slow down. When
the clients aren't getting their data, the users will start
hitting Reload in their browser, and that loads your server
even more. When the load subsides, Apache will evaluate its
situation based on the min and max spare servers settings.
These settings are something you'll need to experiment with after your
web server is in production. You can use "ps
-ef | grep http | wc -l" to figure out how many processes are
running and compare that to your settings. If you guessed right, congratulations,
else adjust the settings and use apachectl to reload the config file. Of
course, if you need more that 256 httpd processes you'll need to adjust
the setting in httpd.h.
- MaxRequestsPerChild: The MaxRequestsPerChild parameter
helps with memory leaks. Once an httpd process serves the number
of requests specified in this parameter it dies. If your system
has leaky system libraries, or something you compiled into
Apache is leaky (PHP, mod_ssl, mod_perl, etc.), or all of the
above (the most likely), the httpd processes will continue
to use more and more RAM until they die or you are out of system
RAM. Since both options are bad, it is best to leave this setting
somewhat high (so that httpd processes aren't always dying)
but low enough to keep your RAM usage down. The default is
10000, and that is usually good enough.
- Dynamic Shared Objects & Modules: Don't use any modules
you don't need! Modules tend to add functionality, but at the
expense of your performance. Modules such as negotiation_module
slow everything down by negotiating content and language. While
their functionality is useful sometimes, you need to be aware
of what they are doing behind the scenes. If you have users
on your server that will be referring to their home directories
(http://wherever.com/~username) you'll need to include userdir_module,
too. Modules you probably want to keep around are:
- autoindex_module (though you may wish to disable indexes)
- anything you specifically compiled in (mod_php, etc)
- Directory options: You can set directory options, such as
FollowSymLinks and AllowOverride, to enable users or content
developers to control server behaviour through .htaccess files.
While this is sometimes desirable, it forces Apache to make
extra filesystem calls every time a document is requested.
The best option is something like this:
Why? If Apache should
not follow symbolic links then it will need to make a call to the filesystem
to determine if the document is a file or a symlink. Similarly, the SymLinksIfOwnerMatch flag
requires a system call to determine the owner of the files involved. With AllowOverride set
to None, Apache will not need to make a system call to determine if there
is a .htaccess file in the relevant directories.
The results of the system call necessary to perform these operations (lsstat)
are not cached by the filesystem. That is why it is important to not use
them unless necessary, as you end up touching the file system every time.
A good discussion of this can be found at the Apache
- Logging & Host Name Lookups: Logging can be intensive
for a popular web site. For this reason, only log what you
need. The HostnameLookups flag
should be off as well. Use a program like logresolve (or better
yet, the resolver that comes as part of the ADNS library) to
do post-processing on the logs. Do it on a separate machine,
away from the web server, or during a time that is not busy.
- Server Status: Enabling the server-status handler
can be a good way to troubleshoot performance and get a feel
for the way things work on your server, but disable it when
you are done. It causes Apache to spend time keeping track
of things you probably don't need during day-to-day operation.
Watch the RS/6000 and AIX. You can use techniques described
in our general AIX tuning document to
tune tcp_sendspace, tcp_recvspace, thewall, and related networking
parameters. You should probably crank the tcp_sendspace and tcp_recvspace
settings to 512 KB or higher, and thewall to something very high.
Depending on your memory settings you may wish to use vmtune
to set minperm and maxperm to something like 10% and 50% and
maxrandwrt to 32 4096 byte pages. Tuning the operating system
and the machine are things you'll need to do continuously, based
on the types of things your RS/6000 is doing.
Other resources: Dean
Gaudet's Apache Performance Notes,
This document compiled by Bob
Corrections and notes should be sent to him.