Managing Child Processes

In the original NCSA (National Center for Supercomputer Applications) web server design, the server would fork processes to handle individual requests. This placed a heavy load on the CPU when the server was busy, and impacted the responsiveness of the server. It was even possible for the entire system to be overwhelmed by HTTP daemon processes.

Apache uses another approach. A swarm of server processes starts at boot time. (The ps command in Listing below shows several httpd processes running on a Linux system.) All of the processes in the swarm share the workload. If all of the persistent httpd processes become busy, spare processes are started to share the work.

Five options in the httpd.conf configuration file control how the child server processes are managed. The options that control the management of these spare processes are as follows:

MinSpareServers Defines the minimum number of idle server processes that must be maintained. In the Red Hat configuration, this is set to 5, which is the default value used in the Apache distribution. With this setting, another process is created to maintain the minimum number of idle process when the number of idle httpd processes drops below 5. Set MinSpareServers higher if the server is frequently slow to respond because of periods of high activity.

MaxSpareServers Defines the maximum number of idle server processes that may be maintained. In the Red Hat configuration, this is set to 20. During a burst of activity, several httpd processes may be created to handle client request. As activity declines, the processes become idle. With the Red Hat setting, processes will be killed if more than 20 httpd processes are sitting idle.

StartServers Defines the number of persistent httpd processes started at boot time. In the Red Hat configuration it is set to 8. The effect of this directive can be seen in the output of the ps command, which showed that nine httpd daemons were running. One of these is the parent process that manages the swarm, but does not serve client requests. The other eight are the child processes that actually handle client requests for data.

MaxClients Defines the maximum number of clients to be serviced. Requests beyond the maximum number are queued until a server is available. Red Hat sets this to 150, which is the most commonly used value. The default used when MaxClients is not defined is the value set by HARD_SERVER_LIMIT when Apache is compiled, which is usually 256. MaxClients prevents the server from consuming all system resources when it receives an overwhelming number of client requests. The Red Hat MaxClients setting should be increased only if the number of simultaneous clients using your server routinely exceeds 150, and your server is a powerful system with fast disks and a large amount of memory. It is often better to handle additional clients by adding additional servers than it is to pack more clients on one server.

MaxRequestsPerChild Defines the number of client requests a child process can handle before it must terminate. Red Hat sets this to a very low 1000. MaxRequestsPerChild is used when the operating system or libraries have memory leaks that cause problems for persistent processes. Apache recommends a setting of 10000 if your system has memory leak problems. Set MaxRequestsPerChild to 0, which means "unlimited"-a child process can keep handling client requests for as long as the system is up and running-unless you know for a fact that the library you used to compile Apache has a memory leak.

The User and Group directives define the UID and GID under which the swarm of httpd processes are run. When httpd starts at boot time, it runs as a root process, binds to port 80, and then starts a group of child processes that provide the actual web services. The UID and GID defined in the httpd.conf file are assigned to these child processes. The UID and GID should provide the least possible system privilege to the web server. On most Linux systems, this is the user nobody and the group nobody. An alternative to using nobody is to create a user ID and group ID just for httpd. Red Hat uses this approach, and creates a special user apache and a special group apache. The advantage of creating a special UID and GID for the web server is that you can use group permission for added protection, and you won't be completely dependent on the world permission granted to nobody. If you create your own user and group for Apache, set the file permissions for the new user account very carefully.