[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 Stein <gstein_at_lyra.org>
Date: 2003-10-23 02:49:16 CEST

On Wed, Oct 22, 2003 at 05:52:08PM -0500, kfogel@collab.net wrote:
> mark benedetto king <mbk@lowlatency.com> writes:
> > > 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:
> >
> > Without client-side threading (eek!) or, AFAICT, a significant neon API
> > change, it would be very hard indeed for ra_dav.
>
> Not necessarily. Ben and I are meeting early tomorrow morning to try
> out a similar idea: make mod_dav_svn return a full tree delta (instead
> of a skelta) for a checkout request, instead of waiting for the
> zillions of GET requests from the client.

Are you talking about embedding the content within the REPORT? Which then
implies that you're going to need to xml-escape or otherwise encode the
binary content.

I don't really support this concept at all. By obviating the GET, you then
toss the possibility of a caching proxy. It also moves us away from the
proper solution...

... which is to implement HTTP pipelining. That would let us jam a bunch
of requests into the connection at once, thus reducing the round trip
latency.

As mbk stated, pipelining would require a change to Neon, or to switch to a
different client library.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 23 02:54:54 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.