On Thu, Nov 6, 2008 at 9:35 AM, Garrett Rooney
<rooneg_at_electricjellyfish.net> wrote:
> On Thu, Nov 6, 2008 at 10:29 AM, Greg Hudson <ghudson_at_mit.edu> wrote:
>> On Thu, 2008-11-06 at 09:18 -0600, Ben Collins-Sussman wrote:
>>> I'd have to defer this question to the serf experts. There's an
>>> unspoken assumption that saturating the pipe with parallel (and/or
>>> pipelined) requests is always a speed gain, but I actually don't know
>>> of evidence to back this up. Maybe it's out there, though.
>>
>> So, ignoring HTTP, the theory is that if you want to transfer a big file
>> really fast, you should open like ten TCP connections and transfer
>> tenth-sized chunks of it in parallel?
>>
>> I really doubt that's any faster, and if it ever is, it's only because
>> you're being a bad network citizen and grabbing a bigger share of a
>> congested pipe.
>
> I believe the assumption is that you'd actually be making pipelined
> requests over a smaller number of TCP connections, not actually
> opening 10 separate ones.
We have no plans break up a huge file and transfer pieces of it in
parallel. Our model is the standard 'commit which changes several
files'. If there are 10 files to be committed, we'd like to do the
10 PUTs simultaneously over multiple connections rather than send them
serially over a single connection. Even if the single connection
sends pipelined write requests (the way ra_svn does), the theory is
that it's faster to send them over multiple connections.
At the moment, serf opens a default of 4 connections for doing GETs in
parallel during a checkout/update. This is the same thing firefox
does.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-06 16:43:16 CET