11
5
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?
But why would that matter? To me, it seems undesirable to ever spread a single user's connection's out over multiple servers. Load balancing is to handle a high number of users, not connections from a single user. In fact - if a single user is hammering a service, you'd rather it be confined to a single server (where they would effectively rate-limit themselves). – Jonathon Reinhart – 2017-02-03T19:30:56.233
1Good points. A few thoughts:
Reason 2 is how I got to this page while searching to see what people had to say about this parameter. – dtauzell – 2017-02-03T22:05:14.343
1A third reason: if your server/app gets into a bad state and is erroring out this pinning can make all the requests error out until the situation is corrected, whereas if you limit how many they have a chance of getting balanced to a new server. – dtauzell – 2017-02-03T22:42:20.113