Re: PaceBatch and pipelining

["Roy T. Fielding" <fielding@xxxxxxxx>]

On Jun 28, 2005, at 12:16 AM, Phil Ringnalda wrote:
> Mark Baker wrote:
> > On Mon, Jun 27, 2005 at 10:11:01PM -0700, Robert Sayre wrote:
> > > In my experience, pipelining facilities have hardcoded limits. By 
> > > default, it's 100 requests in Tomcat, and 8 in Mozilla.
> > I'm not worried about the Tomcat number at all, as the overhead of a 
> > new
> > TCP connection is amortized over that many messages.  The Mozilla 
> > limit
> > just seems to reflect the point at which it becomes more efficient to
> > open a new connection anyhow.  But you're certainly free to have two 
> > or
> > more pipelines active to the same server, so I see no issue with that.
> > BTW, both values are configurable, not hard-coded, except that 100
> > is the hard-coded default for Tomcat it seems.  Also, FWIW, my Firefox
> > uses the default value 4 (getting awfully close to the HTTP/1.0
> > value, 1 8-).
>
> From what I've been able to piece together from reading bugs and code 
> comments, the Mozilla hard upper limit of 8 is based mostly on the 
> desire to not over-commit to pipelining when faced with a server that 
> claims to support HTTP/1.1, but returns garbage on pipelined requests.

Mozilla is a graphical browser, not an Atom client (yet).  Such limits
on the client side are balancing slow-start versus parallelism (with
a touch of good Internet citizenship on the side).  They have nothing
to do with the capability of pipelining.

On the server side, a default of 100 is specifically to prevent
denial-of-service attacks and preserve robust behavior in the
presence of potential application memory leaks.  It is configurable
on most servers.

This is roughly the 8th or 9th proposal that I have seen to add
some form of batching to HTTP.  All of them failed to provide
sufficient use cases that were actually more efficient than
separate requests, even without taking into account more forward
thinking like:

   1) how does it impact load balanced services?

   2) what is doing the request dispatch and WTF happens when you
      ask hardware developers to implement a special-case for
      request dispatching just because Atom thinks it is special?

   3) if the app-level protocol is upgraded, can the implementation
      benefit from those improvements or does it get relegated
      to legacy support.

Subversion uses the REPORT method as a means of (very dumb)
pipelining.  However, the reason for doing so was because their
client implementation did not support pipelining yet.

If you look at the actual bytes on the wire, there is no benefit
to batching heterogeneous requests (go ahead and count them, being
sure to include the extra bytes needed to introduce the batch).
Even if you are using two cups and a string to connect to your ISP,
the additional overhead of checking every request body for a batch
and the resulting duplication of most of HTTP's functionality
inside the Atom request handler, as opposed to just letting the
httpd code do it all for you, makes batching methods a bad design
choice overall.

The only case that I have experienced where batching methods
actually provide a net win on average is when the exact same
request is applied to many different URIs.  That is consistent
with the experiences described by Nelson, "mail read/unread", etc.
However, the pace is not optimized for that case, and even if it
were, the real benefits don't kick in until the transfer protocol
is aware of the multi-target request and able to dispatch and
reply asynchronously. [Yes, Mark, that is in waka too.]

-1

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>