Re: HTTP protocol v2: rethunk.

On Thu, 2008-11-06 at 09:43 -0600, Ben Collins-Sussman wrote:
> 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.

Apparently my example was too clever, and used the wrong magic number.

Say I have four files I want to get from computer A to computer B.

  Plan #1: Open four TCP connections in parallel, send the four files.

  Plan #2: Concatenate the four files together (with some kind of
separator), open one TCP connection, and send the concatenation.

If plan #1 is ever faster than plan #2, I strongly suspect it's only
because it's grabbing a larger share of a congested pipe. I don't know
why anyone would think four TCP connections between the same two
endpoints would intrinsically have more bandwidth than a single
connection.

---------------------------------------------------------------------
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:55:57 CET