Why would you ever set MaxKeepAliveRequests to anything but unlimited

apache-http-serverhttpkeepalive

Apache's KeepAliveTimeout exists to close a keep-alive connection if a new request is not issued within a given period of time. Provided the user does not close his browser/tab, this timeout (usually 5-15 seconds) is what eventually closes most keep-alive connections, and prevents server resources from being wasted by holding on to connections indefinitely.

Now the MaxKeepAliveRequests directive puts a limit on the number of HTTP requests that a single TCP connection (left open due to KeepAlive) will serve. Setting this to 0 means an unlimited number of requests are allowed.

Why would you ever set this to anything but "unlimited"? Provided a client is still actively making requests, what harm is there in letting them happen on the same keep-alive connection? Once the limit is reached, the requests still come in, just on a new connection.

The way I see it, there is no point in ever limiting this. What am I missing?

Best Answer

Basically, because Apache wasn't built for it. The problem is server memory usage. In many configurations, content generation is done in the same process as content delivery, so each process will grow to the size of the largest thing it handles. Picture a process expanding to 64mb because of a heavy php script, then that bloated process sitting and serving static files. Now multiply that by 100. Also, if there are memory leaks anywhere, processes will grow without limit.

The keepalive settings should be balanced based on the type of your content and your traffic. Generally, the optimal configuration has MaxKeepAliveRequests high (100-500), and KeepAliveTimeout low (2-5) to free them up quickly.

Related Question