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

Re: Relative performance of http:// vs. svn://

From: Jean-Marc Godbout <jmgodbout_at_gmail.com>
Date: 2005-09-20 18:36:25 CEST

Listen to Paul :)

What I meant was request-responses. And due to how they are done, you can't
buffer them... the server not knowing what the client will request next.

On 9/20/05, Paul Koning <pkoning@equallogic.com> wrote:
> >>>>> "Jean-Marc" == Jean-Marc Godbout <jmgodbout@gmail.com> writes:
> Jean-Marc> In fact, there are two issues for "ls". 1. Issue 1161:
> Jean-Marc> Too many packets being sent. This is especially costful in
> Jean-Marc> high latency networks.
> The statement I just saw was different -- too many request/response
> exchanges.
> Sending lots of packets is not always costly even on high latency
> networks. If the network stack has adequate buffering, and the
> application can "just pour packets down the pipe" then things will go
> fast even on high latency networks.
> Conversely, if the application sends a packet, waits for a response,
> sends another packet, etc., then its performance will be terrible on
> ANY network.
> Applications like Subversion, when doing "bulk" operations, need to
> work hard to avoid request/response operation. A checkout is a nice
> example of how you want things to operate: once it's in progress, the
> server just sends a long stream of data. That's the right way for any
> network.
> paul
Received on Tue Sep 20 20:25:51 2005

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

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