That was a very interesting article, thanks. One question, if I may: When using a reverse proxy, it makes no sense to have keepalives on for Apache, correct? The proxy takes care of the keepalive and leaves Apache free for other requests?

Correct. The reverse proxy pulls from the fast, local network apache, and then passed the data to the slow clients. Apace is connected for a shorter time. Basically you're trying minimize the time a "memory expensive" process like apache is open per client.

Yep, makes perfect sense, thank you. I've disabled keepalive and increased my mancrush on varnish.

Could you expand on the tuning of tcp slow start? Are you referring to net.ipv4.tcp_slow_start_after_idle?

No, I'm not referring to this parameter in the write up. ipv4.tcp_slow_start_after_idle, which is on by default on most distros, applies to keepalive connections. This causes your keepalive connection to return to slow start after TCP_TIMEOUT_INIT which is 3 seconds. Not probably want you want or expect. For example, if you have keepalives of say 10s, you'd expect that a request after say 5s would have it's congestion window fully open from previous requests, but the default behaviour is to go back to slow start, and close your congestion window back down. So you want to tune this to off on your image servers and other keepalive systems.

The tuning which I talk about is to actually increase the default initial congestion window size. The result being an advantage for non-keepalive connections and keepalives. There is no sysctl parameter that will allow for this control. This behaviour is hardcoded into the tcp stack, and hence requires direct modification and a recompiled kernel.

This is a really good intro on tuning a high bandwidth site; thx!