The Apache HTTP server has a configuration directive that everyone knows about since Apache 1.1 : MaxKeepAliveRequests.
It defaults to 100.
People usually keep the default value or sometimes reduce it in order to save memory on small boxes.
Like a lot of other Apache keywords, MaxKeepAliveRequests is confusing. I sounds as if it was the total number of concurrent processes serving multiple HTTP requests on the same TCP connection.
But it’s not.
It’s actually the maximum number of requests to serve on a TCP connection. If you set it up to 100, clients with keepalive support will be forced to reconnect after downloading 100 items.
Lighty has a similar variable: server.max-keep-alive-requests.
What’s the point? The keep-alive mechanism is good, why not just serve as many requests as necessary? In order to work around browsers bugs (IE + HTTPS and upload), why not just use the enable/disable keep-alive button?
A few days ago, I had a server with high system load. It was actually waiting a lot for the disk. That host serves pages with a lot of small images, about 500 images for a single page, plus CSS and Javascript files. It was running Apache, mostly in its default configuration. MaxKeepAliveRequests was bumped to 1000. Immediately, the system load decreased, there were less running processes and less wait for disk I/O. Just because clients could download a full page with a single connection. Bumping that value didn’t had any negative impact, it only made everything snappier.
So: set MaxKeepAliveRequests to more than the maximum number of elements you will be serving for a web page. More than 100 is common these days. You can also set it to 0 to have it unlimited.