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