In fact, there are two issues for "ls".
1. Issue 1161: Too many packets being sent. This is especially costful in
high latency networks.
2. Issue 2151: There is a delay in the generation of the packets on the
The second issue has two impacts:
2.1 - The server can takes a long time before sending the data.
2.2 - There is WAY TOO MUCH data being sent.
#2 already has a patch in the pipeline, it improves ls times alot. ls was an
example of an especially wasteful operation - I'm not sure there are
equivalent improvements for the rest.
On 9/20/05, John Waycott <firstname.lastname@example.org> wrote:
> Paul Koning wrote:
> > John> Some testing my group has done (I don't have exact figures
> > John> here) showed that for us the biggest issue seems to be network
> > John> latency. If the ping times between the server and client are
> > John> short, you may see less of a difference. The round-trip ping
> > John> times between some of our offices is about 500ms. For
> > John> checkouts, we see svn:// about 2-3 times faster than
> > John> http://. We see very little difference when accessing the
> > John> repository from the local LAN. 'svn ls' over http:// is
> > John> excruciatingly slow, never taking less than 10 seconds to even
> > John> get a response back. With svn:// it takes maybe 2 seconds.
> >I'm a bit confused whether you're saying the two are a lot different,
> >or not different.
> >Anyway, I've been doing a whole bunch of tests on a large repository
> >(71k files) on a local LAN, fast server, pretty fast client. (Server
> >is Linux, client is NetBSD.)
> >svnserve is consistently significantly faster. Specifically:
> >checkout 20:37 vs. 32:52
> >switch 8:55 vs. 21:32
> >status 3:53 vs. 5:21
> >update 6:30 vs. 9:01
> The slowness we experience with http: seems to do more with the number
> of packets sent rather than the number of bytes. On our LAN, the
> round-trip time between my workstation and our svn server is less than
> 1ms. Our developers in Russia experience a round-trip time of about
> 500ms between client and server. We are working to upgrade our network
> which will reduce the latency.
> The 'svn ls' experiment, for example, 20 packets are exchanged between
> the client and server when running over http: before anything really
> happens. This translates to a 10-second delay for the remote users, and
> an unnoticeable 16ms delay for local users. svn: is faster on our LAN,
> the difference is just not as dramatic as it is for our Russian office.
> I'm glad we aren't using satellite links for connecting our remote
> offices :-)
> To unsubscribe, e-mail: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Sep 20 20:26:36 2005