Aryeh Gregor wrote:
On Thu, Sep 24, 2009 at 4:41 AM, Tim Starling tstarling@wikimedia.org wrote:
* Removes a few RTTs for non-pipelining clientsDo you mean to imply that there's such a thing as a pipelining client on the real web? (Okay, okay, Opera.) This concern seems like it outweighs all the others put together pretty handily -- especially for script files that aren't at the end, which block page loading.
It's not really as simple as that. The major browsers use concurrency as a substitute for pipelining. Instead of queueing up multiple requests in a single TCP connection and then waiting, they queue up multiple requests in multiple connections and then wait. The effect is very similar in terms of RTTs.
By concatenating, you eliminate concurrency in the browser. The effect of this could actually be to make the initial page view slower, despite the increased TCP window size at the end of the concatenated request. The net performance impact would depend on all sorts of factors, but you can see that the concurrent case would be faster when the RTT is very long, the number of objects is large, the number of connections is equally large, and the unmerged object size is slightly smaller than the initial TCP window.
In a default install, it's not harmful to concatenate the [[MediaWiki:*.css]] pages regardless of network distance, because the pages are so small that even the merged object will fit in the initial TCP window.
There is a potential reduction in RTT count due to concatenation, that's why I included that item on the list. But it's client-dependent and might not exist at all in the most common case. That's why I'm focusing on other benefits of concatenation to justify why I'm doing it.
-- Tim Starling