[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Link latency and ra_svn/ra_dav performance

From: mark benedetto king <mbk_at_lowlatency.com>
Date: 2003-10-23 14:24:20 CEST

On Thu, Oct 23, 2003 at 03:01:25AM -0400, Greg Hudson wrote:
> On Wed, 2003-10-22 at 23:08, kfogel@collab.net wrote:
> > We haven't looked into pipelining & Neon much yet; the above is just
> > talk until we know more.
> As Greg said, the current implementation of Neon doesn't support
> pipelining. I just looked at the code to verify this;
> ne_begin_request() reads the response headers before returning control
> to the caller, and the code is very much not designed to handle multiple
> ne_begin_request()s before an ne_read_response_block().

Also, ra_dav itself would probably need some serious tweakage to
take advantage of the new API.

> I think if we can get a significant checkout performance benefit by
> screwing caches, we should do so as a temporary measure. We have no
> reports of anyone using HTTP caches as far as I know, and it makes no
> sense to massively penalize all of our users for the sake of none of our
> users. Redesigning Neon or moving to a different client library is not
> a pre-1.0-sized task.


> I would even go so far as to say that we should temporarily screw the
> WebDAV protocol for commits and imports, and just send the edit over a
> custom report, if someone is willing to code that up. (Are big imports
> all that frequent? Not normally, but it's the first thing you do in
> many uses of Subversion, and up-front slowness is sometimes worse than
> frequent slowness.)

Are there any real drawbacks to this other than that they'll distract us
from the maintainance/tuning of the core WebDAV operations?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 23 14:25:31 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.