Re: Pipeline hinting revisited

Hi Brian,

On Thu, Aug 11, 2011 at 03:12:31PM -0700, Brian Pane wrote:
> I've been thinking some more about request pipelining recently,
> triggered by several observations:
> 
> - A significant number of real-world websites could be made faster via
> widespread adoption of request pipelining (based on my study of
> ~15,000 sites in the httparchive.org corpus).
> - A nontrivial fraction of mobile browsers are using pipelining
> already, albeit not as aggressively as they could (based on Blaze's
> study: http://www.blaze.io/mobile/http-pipelining-big-in-mobile/ )
> - Client implementations that currently pipeline their requests are
> using heuristics of varying complexity to try to decide when
> pipelining is safe.  The list of conditions documented here is at the
> complex end of the spectrum, and it's perhaps still incomplete:
> https://bugzilla.mozilla.org/show_bug.cgi?id=599164
> 
> The key question, I think, is whether heuristics implemented on the
> client side will end up being sufficient to detect safe opportunities
> for pipelining.  If not, a server-driven hinting mechanism of the sort
> proposed in Mark's "making pipelining usable" draft (
> http://tools.ietf.org/html/draft-nottingham-http-pipeline-01 ) seems
> necessary.
> 
> Anybody have additional experimental data on pipelining (including the
> effectiveness of heuristics for turning pipelining on or off) that
> they can share?

We've been conducting some tests for a customer working with mobile
terminals. I was very frustrated to see that pipelining did not bring
any gain there due to the first non-pipelined request to each host.
What happens is that there are many objects on a page, spread over
many hosts. The terminal opens many parallel connections to these
hosts, and as a result, there are 4-5 objects max to fetch over each
connection. All connection have a first object fetched alone, and only
once a response is received, a batch of 4 requests is sent. It is this 
pause between the first and the next request over a connection which
voids the gain. It was always faster to open more parallel connection,
despite the extra bandwidth, than to use pipeline, precisely due to
this point.

This is why I think we need to find a solution so that pipelining could
be more aggressive on riskless requests, and possibly use the server
side's hinting to safely fall back to non-pipelining ASAP if needed.
I'm well aware that the biggest issue seems to be with broken servers
getting stuck between requests. I don't know if there are many of those
or not, but maybe at one point it will become those site's problem and
not the browsers'.

Also, another important thing to note is that (especially in mobile
environments), the highest latency is between the terminal and the
ISP's infrastructure, where interception proxies are quite common.
It would be a tremendous help to be able to use pipelining by default
without hinting, because these interception proxies generally support
pipelining very well and are the only ones for whom it's important.
That way we could have a terminal always pipeline requests and the
interception proxy do whatever it likes on the last 10-millisecond
segment.

Regards,
Willy

Received on Friday, 12 August 2011 05:32:14 UTC