Aryeh Gregor wrote:
On Thu, Sep 24, 2009 at 4:41 AM, Tim Starling
<tstarling(a)wikimedia.org> wrote:
* Removes a few RTTs for non-pipelining
clients
Do 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