HTTP Pipelining performance

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

HTTP Pipelining performance

Boris Zbarsky
I've been looking at the way we kick off loads (due to working on bug
84582 again), and I am once again reminded of how nice pipelining would
be.  For example, in the following code:

   <link rel="stylesheet" ...>
   <script />
   Lots of body HTML.

We currently don't kick off the script load until the stylesheet loads.
  If bug 84582 is fixed, we'd kick off the load immediately, but it
wouldn't hit the wire until either the sheet loads or the page HTML
finishes coming in (2 connections per server limit, with keepalive).  Of
course if pipelining were enabled we could kick off the script load

I realize pipelining is hard to do because of server issues, but do we
at least know which servers have problems?  Or have a list of servers
known to not have problems?

If we do, it seems to me that we could just maintain a cache of
host+port -> boolean indicating whether the server supports pipelining
in necko.  If something's not in the cache, default to no pipelining.
When we get a response from the server, look at the Server: header and
populate the cache accordingly... (either default to true and set false
if the server is on a blacklist, or default false and set true if server
is on a whitelist or something).  That way the original connection that
we fetch the page HTML over will not be pipelined, but the second
connection that we set up once we need to start getting
images/scripts/styles would be.  We could even close the non-pipelined
connection once we have all the HTML and reopen a pipelined one or

Of course all this is predicated on pipelining really helping
performance.  It seems like it should, but do we have any hard data on this?

dev-performance mailing list
[hidden email]