Apache Performance Tuning

Understanding Apache Tuning

When Apache gets flooded with connections, sometimes the server will stop responding to requests even though the CPU isn’t maxed out and the disk IO is not a problem. You can think of the limiting metrics in Apache like a onion which are ordered as follows:


This is the number of Apache connections that can be established simultaneously. If you have a large connection load for static content, but there are not enough connections to service the static content, then dynamic content may get starved by serving static content. You want to make sure that your connection limit is high enough to service all connections so that static content can be served quickly.


This is the maximum number of requests to the server. Any requests over this value are queued. This number should be smaller than the ServerLimit, and probably should be set to some multiple of the number of CPU cores on your system. Keep raising this value until your CPU is maxed out.


If you are using FastCGI (fcgid) then there are two tuneables that you need to pay attention to. The first is the minimum number of FastCGI processes that are to be spawned when Apache starts. These are ready and waiting to handle new requests. You can set this value as low as 0, but then a new CGI process (typically PHP) will need to be spawned with the first new connection. By having them wait, they are available to service the request immediately which minimizes PHP startup time. On newer versions of PHP that support opcode caching (built-in or using something like xcache), the cache is hot in the running process.


This is the maximum limit for the number of FastCGI processes. You probably want this to be a multiple of your CPU count but small enough that you do not run out of memory. If you have plenty of memory and your CPU is not saturated, then increase the maximum limit to handle as many PHP processes as possible.


This is the maximum number of connections a child will handle before being reaped. If child processes have memory leak issues, this will limit its impact on the server.


This allows connections to persist and handle multiple requests.


If KeepAlive is enabled, this sets how long (in seconds) a connection should persist. If the timeout is too long then a connection to the web server is open but not being used which will push your server connection count toward your ServerLimit. A range from 3-60 seconds is probably reasonable, but test for your configuration. If you have severe contention because of lots of contention and KeepAlive‘s are starving the server, then you can disable KeepAlive.


If KeepAlive is enabled, this sets the maximum number of requests a single connection can handle before closing.


This sets the maximum time (in seconds) a request can be made before it gives up and times out.

We have tuned many Apache servers, so let us know if you need help!