Re: HTTP protocol v2: rethunk.

Ben Collins-Sussman wrote:
> I'd have to defer this question to the serf experts. There's an
> unspoken assumption that saturating the pipe with parallel (and/or
> pipelined) requests is always a speed gain, but I actually don't know
> of evidence to back this up. Maybe it's out there, though.
>

It's easy to explain.

For parallel requests: If latency is truly the bottleneck, then running
two queries in parallel effectively cuts the latency in half for the
total effect. If any network routers are performing rate limiting or
packet prioritization, having two independent sessions often doubles the
bandwidth that such a system will grant you. Having two queries in
parallel means two Apache processes both serving your request. Latency
is further reduced in that the request/response cycle is not spending
idle time waiting for the request to be processed. The network pipe can
be filled with responses alternating or interleaved.

For pipelining requests: This is purely about latency of the
request/response cycle. Sending all the requests in advance means that
they can all be processed earlier, meaning that the pipe can be filled
with data sooner, and the pipe will not "empty" between requests. It
will be full for the entire transaction.

> In the case of doing a checkout/update, my understanding is that
> ra_serf's parallelism is 'slightly' faster than ra_neon's single
> request/response. The response I've always gotten back from
> gstein/jerenkrantz about this is that ra_serf is going to really shine
> when caching proxies come into play. This makes sense to me: even if
> there's no obvious, immediate benefit to most users doing checkouts
> over serf, the design is a bit of investment in the future, and should
> be especially beneficial to corporations with caching infrastructure.
> It's not clear to me that parallel PUTs have the same promise, though
> -- caching proxies don't help with that.
>
> My instinct is to ask somebody to measure parallel PUTs vs.
> single-request, so we have hard data to examine. But nobody's
> implemented the parallel PUTs yet

I'd like to see Subversion escape from the HTTP-based request/response
for minor operations model. The protocol is chatty which leads to high
latency. Pipelined PUT might not be that much better but a "COMMIT" that
included all content in one HTTP request should be...

Cheers,
mark

-- 
Mark Mielke <mark_at_mielke.cc>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org