Building an Optimized Apache 1.3 for AIX:

1. 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 good, either.
   
   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
   
   
2. Get the Apache software from http://httpd.apache.org/ or a local mirror. Extract the software to a sensible location.
   
   
3. 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.
   
   
4. 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.
   
   
5. 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.
   
   
6. 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 --enable-shared=max --prefix=/usr/local/apache
   
   
7. Install Apache (make install).
   
   
8. Edit httpd.conf. Here are some thoughts on certain settings:
   
   
• 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, MaxSpareServers, StartServers, 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.
  
  MaxClients is 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:
  
  
  • env_module
  • config_log_module
  • mime_module
  • autoindex_module (though you may wish to disable indexes)
  • dir_module
  • cgi_module
  • alias_module
  • access_module
  • 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:
  
  <Directory />
  Options FollowSymLinks
  AllowOverride None
  </Directory>
  
  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 web site.
  
  
• 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.
  
  
9. 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.
   
   
10. 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.
    
    
11. Other resources: Dean Gaudet's Apache Performance Notes,

 

This document compiled by Bob Plankers (plankers@doit.wisc.edu).
Corrections and notes should be sent to him.