couchdb-replication mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yaron Goland <>
Subject RE: _bulk_get protocol extension
Date Tue, 28 Jan 2014 03:26:44 GMT
Sorry for the delay in getting back to this mail thread. I talked with Mark Nottingham, chair
of the HTTP WG in the IETF, who, to be clear, is in no way responsible for the content of
this email.

Nevertheless he did say that so long as one probes the connection then pipelining is known
to work. Probing just means that you can't assume that the server you are talking to is a
1.1 server and therefore supports pipelining. So you have to make the first request, get back
a 1.1 response and only then make the second and subsequent requests with pipelining.

I would think it would be easier to teach people how to do probing than to introduce a completely
new compound message format. But I recognize that is just my opinion, not a fact.

So please just take this a comment from the peanut gallery.



> -----Original Message-----
> From: Jens Alfke []
> Sent: Friday, January 24, 2014 11:36 AM
> To:
> Subject: Re: _bulk_get protocol extension
> On Jan 24, 2014, at 9:35 AM, Yaron Goland <> wrote:
> > In the HTTP WG more than a decade ago issues like this came up under the
> name 'boxcar'ing'. But with the introduction of pipelining the performance
> benefits of boxcar'ing for idempotent requests went away.
> It's not that simple. Pipelining has problems, as described by Ilya Grigorik in
> his excellent new book "High Performance Browser Networking":
> >> In practice, due to lack of multiplexing, HTTP pipelining creates
> >> many subtle and undocumented implications for HTTP servers,
> intermediaries, and clients: [...] Due to these and similar complications, and
> lack of guidance in the HTTP 1.1 standard for these cases, HTTP pipelining
> adoption has remained very limited despite its many benefits. Today, some
> browsers support pipelining, usually as an advanced configuration option, but
> most have it disabled.
> -
> In my case, pipelining is off by default in Apple's HTTP client framework, and
> I've been loath to turn it on for reasons like those Grigorik describes. (Also,
> IIRC I tried turning it on a year or so ago and ran some replication
> performance tests, and didn't see noticeable improvements.)
> Coalescing everything into one request also removes the overhead of
> generating and parsing each HTTP request/response, on both client and
> server sides.
> -Jens

View raw message