[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-10-22 23:41:04 CEST

On Wed, 2003-10-22 at 16:52, Tobias Ringström wrote:
> The current implementation of both ra_svn and ra_dav are implemented
> without overlapping requests. In other words they always wait for the
> response from the server for the previous request before sending the
> next request.

That's not true; ra_svn defers the responses to many requests in order
to reduce the round trip count.

> So what do you think? Can we make the protocols streamy? Should I create
> an issue?

The big question is, "how?" I think it would be especially hard with
ra_dav, but just thinking about ra_svn, here are the options I see:

  * Defer edit errors until close_edit(). This would destroy the
property that commits fail before file data is transmitted, and would
mean that if a big import fails close to the beginning, the client
wouldn't find out until it has transmitted all the data.

  * Defer edit errors until close_dir(). This wouldn't make the
protocol quite as streamy as you'd like, but would preserve the commit
property and would reduce the number of round trips. It would also mean
that big imports would fail reasonably quickly after an error occurs.

  * Add a new editor function called something like
get_deferred_error(), which would be optional to implement (the default
implementation returns SVN_NO_ERROR). Defer ra_svn errors until
close_edit or get_deferred_error time. The driver then gets to decide
how to trade off round trips versus failure latency. commit might call
get_deferred_error() just once before sending the postfix deltas; import
might call it once per directory or something.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 22 23:41:56 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.