[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: <kfogel_at_collab.net>
Date: 2003-10-23 05:08:45 CEST

Greg Stein <gstein@lyra.org> writes:
> 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.

I'm open to any solution that will work in a reasonable amount of
time, and am certainly not committed to an approach that hasn't even
really been tested experimentally yet.

That said, there is no way that we are going to take a huge up-front
perf hit in order to help out caching proxies. Those would be
backwards priorities. If the "obvious" solution turns out to have
negative effects on proxies, yet gets us (say) a 5x speedup on a
normal latency network, then screw the proxies. I mean, sheesh :-).

We haven't looked into pipelining & Neon much yet; the above is just
talk until we know more.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 23 05:46:11 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.