Re: Pipeline hinting revisited

On Thu, Aug 11, 2011 at 10:31 PM, Willy Tarreau <w@1wt.eu> wrote:

> 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'.
>

Often it is a bad intermediary (transparent proxy).  The origin server may
be just as helpless as the client :-(

-Darin



>
> 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
>
>
>