Ben Collins-Sussman wrote:
> On Thu, Nov 6, 2008 at 9:54 AM, Greg Hudson <ghudson_at_mit.edu> wrote:
>
>> 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.
>
> I'm clearly out of my league here; perhaps a degree in computer
> science would have helped me here.
>
> From talking to a friend, the story I hear is that the parallel
> solution might be faster only in the situation of a congested pipe.
> That is, because TCP only allows a certain number of packets to be 'on
> the wire' at once, sending the files serially over a congested network
> may cause more waiting overall. (Send max data allowed; wait for
> response; repeat.) In an uncongested LAN environment, there'd be no
> noticeable speedup at all.
>
> All that said, I'll let gstein and jerenkrantz speak up here... I
> shouldn't be arguing their opinions for them. :-) Personally, I
> much prefer the "whole commit in a single HTTP request" method -- it's
> easier to code, easier to understand, and doesn't open up FSFS or
> libsvn_fs_bigtable to data-stomping race conditions.
The performance aspects of the new protocol are important, but I think it's more
important to determine what you can do with the new protocol.
I understand it's easier to code, but I would like to see a new protocol that
exposes the entire svn_fs.h and svn_repos.h APIs to remote clients, including
the ability for multiple clients to work in the same transaction, just as now
multiple processes that have direct access to the repository can all do work in
the repos.
Where I'm coming from is treating the svn_fs.h API as a versioned filesystem,
ignoring the version control aspects of svn, so making this available via HTTP
could be useful and have interesting applications available in the future.
Blair
---------------------------------------------------------------------
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 18:28:49 CET