Why would you ever set MaxKeepAliveRequests to anything but unlimited?

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?

Solution 1:

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.

Solution 2:

I know this is a old question, but I have been doing some debugging, and it seems as (and this is not only true for Apache) MaxKeepAliveRequests works independently of KeepAliveTimeout.

Meaning, the timeout directive only counts against idling persistent connections (no reads or writes) - if you keep requesting below the timeout you can virtually do an unlimited amount of requests over the same connection.

This might not be good for some reasons including long running tcp connections being randomly killed? In any case, http clients are not that stupid and can handle a "low" MaxKeepAliveRequests setting pretty well, e.g. it is relatively easy in programming language to detect if a tcp connection has been closed by the server and thus re-connecting to it again. Additionally, most of the http-clients are going to have limits in place on their own (e.g. browsers would close a keep-alive connection after 300 seconds or so).