Processes and Limits

This page provides the following options, which set many of the limits for Apache. Generally, the defaults are reasonable, but may need to be altered for high load or low memory situations. The options on this page cover two distinct but related limits that are configurable in Apache.

The first set of limits is related to the length or number of request headers that will be accepted by the server. A request header is a term that refers to all of the information that a client sends to the server to indicate the object it would like to receive. The most important portion of the request header is usually made up of the HTTP method (such as GET, POST, HEAD, and so on), the URI (the complete path and domain name of the object being referred to), and the HTTP protocol version number.

The second set of limits refers to connection and process specific limits of Apache. Apache usually operates in what is known as a process-per-connection mode, wherein each client connection to the server will be served by a single and independent httpd process. Thus to provide service to 30 simultaneous clients, the system will run 30 Apache processes.

Maximum headers in request

Sets the maximum number of request headers accepted per request. Each time a web client (usually a web browser) makes a connection to a web server, it includes request headers to indicate information about the encoding capabilities, HTTP version support, cache-control, content negotiation and other information about the client agent. As HTTP standards and non-standard extensions to the HTTP protocol have been developed, the number of request headers usually received has risen slowly, but is rarely more than 20. The LimitRequestFields [http://www.apache.org/docs/mod/core.html#limitrequestfields ] directive in the Apache configuration file is modified by this option and usually defaults to 100.

It may be possible to prevent certain types of denial-of-service attacks by restricting the number of headers accepted, though it is unlikely the be a problem at the default value. It should rarely need to be altered from its default, unless clients receive error messages from the server indicating too many headers were in the request.

Maximum request header size

Defines the maximum header field size that will be permitted. Apache sets aside a buffer for processing of header entries received from the client. This buffer must be large enough to contain a single header entry in its entirety. The LimitRequestFieldsize [http://www.apache.org/docs/mod/core.html#limitrequestfieldsize ] directive is modified by this option, and it usually defaults to 8190 and this value is also the normal maximum value possible. It is worth noting that the maximum value for this option is system dependent and is compiled into the Apache executable when it is built. Raising this value above the default of 8190 may not be supported on your Apache and should not be necessary under any normal circumstances.

Maximum request line size

Defines the maximum length of an HTTP request line. The request line contains the HTTP method, the complete URI, and the protocol version. The accepted line size needs to be long enough to contain any resource name on the system, and the default is generally recommended. This option edits the LimitRequestLine [http://www.apache.org/docs/mod/core.html#limitrequestline ] directive in the Apache configuration and defaults to 8190 bytes, which is also usually the compiled-in upper bound for this value.

This option rarely needs to be altered from its default, but may be useful in preventing certain types of denial-of-service attacks by preventing client applications from overloading the server with many extremely large and complex request lines.

Maximum concurrent requests

The maximum number of allowed concurrent requests. Each request to Apache spawns a new daemon, and this defines the upper limit on how many such daemons will be spawned to answer requests. This option correlates to the MaxClients [http://www.apache.org/docs/mod/core.html#maxclients] directive. To configure more than 256 you will probably have to edit HARD_SERVER_LIMIT entry in httpd.h and recompile your Apache, unless the package that is installed has already been configured for high loads or you did so when building Apache from the source tarball.

Except in extremely high load environments it is rarely beneficial to raise this to very high levels. Because every new process requires resources, in the form of memory and CPU time, it can be counterproductive and cause service to become less responsive rather than more. If all processes are busy, the request will usually be queued up to the limit imposed by the listen queue length discussed in the next section of this chapter.

Maximum requests per server process

The maximum number of requests that each child process will answer before being killed and respawned. This is useful for a couple of reasons. First, if there are any accidental memory leaks (anywhere in the process, including its modules), the damage can be minimized by restarting processes regularly. Also, without using this option the system will always keep alive the largest number of processes it has ever needed, even during low load periods when far fewer processes are needed to answer requests. This option correlates to the MaxRequestsPerChild [http://www.apache.org/docs/mod/core.html#maxrequestsperchild] directive.

Note 

On Keepalive requests, only one request is counted per connection from a client. Thus, a number of requests from the same client may be served before the counter is incremented if the client supports Keepalive requests. In this case, this directive acts to limit the number of connections per process rather than number of individual requests.

Maximum spare server processes

This defines the maximum number of unused server processes that will be left running. This option configures the MaxSpareServers [http://www.apache.org/docs/mod/core.html#maxspareservers] directive and defaults to 10. There is usually no need to tune this option, except on extremely high load servers.

Caution 

Though Apache is historically a quite solidly written program, and has rarely exhibited major memory leaks, many of the shared modules in use by Apache may not be quite as commonly used or as well tested. These modules may lead to memory leakage even if the Apache httpd process does not exhibit such leakage.

Minimum spare server processes

The minimum number of child processes that will be left running at all times. For high load servers, this may need to be raised, and for low memory and low load systems it might be best to reduce the number. This option correlates to the MinSpareServers [http://www.apache.org/docs/mod/core.html#minspareservers] directive and defaults to 5.

Caution 

It is a very common mistake to raise the above two options to extreme levels when performance of an Apache installation seems sluggish. It is very rarely actually the source of the problem, but it seems a popular first reaction among new Apache administrators. Tuning Apache for performance is well documented in a number of locations, and much documentation about tuning for specific OS platforms is also available on the Internet. A good place to start is the Apache Performance Notes page [http://httpd.apache.org/docs/misc/perf-tuning.html ]. The documentation found there will address nearly all performance issues that most users will ever run into.

Initial server processes

The number of child processes that are spawned when the httpd is started. Correlates to the StartServers [http://www.apache.org/docs/mod/core.html#startservers] directive and defaults to 5. This usually does not need to be modified, except on high load servers.

Display extended status information

If the status module is enabled on the server, turning this on will keep track of extended status information for each request and present them in a web page or machine readable format. This option edits the s ExtendedStatus [http://httpd.apache.org/docs/mod/mod_status.html] directive. This option requires the mod_status module to be loaded.

Note 

To access the extended status information from a running Apache server, you can browse to the address [ http://www.yourdomain.com/server-status]. Note that access control should generally be configured to tightly restrict access to this URL, as it may contain sensitive data about your web server environment.

The information provided by mod_status, with extended status enabled, includes statistics about the number of child processes and the number of connected clients, the average number of requests per second being served, the average number of bytes per request, and the current CPU percentage being used by each Apache process. A machine readable form of this data may be collected from [http://www.yourdomain.com/server-status?auto]. The latter is ideal for use in scripts to gather statistics from your server automatically.

Caution 

Because of the persistent nature of this type of data, this module is only functional when Apache is run in standalone mode, and not when run in inetd mode. Because of the large number of problems involved in running Apache under inetd, and problems inherent to inetd, it is simply best to avoid inetd altogether, anyway.