There ARE NO "turnarounds". You just pipeline a bunch of PUTs up
there. For all intents and purposes, it *looks* like one big mother
request.
Don't forget that a commit also has COPY and DELETE operations going
on, too. And in the future, maybe a MOVE or two :-)
IMO, it is easier to understand if you keep the operations separate
rather than glom them all into one bigass request. Those big glommed
requests then need to be parsed to be broken up. They also don't
restart very well in the face of network failure, packet drops, or
connection closures.
Cheers,
-g
On Mon, Nov 10, 2008 at 7:28 AM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> On Thu, Nov 6, 2008 at 10:23 AM, Ben Collins-Sussman
> <sussman_at_red-bean.com> 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.
>>
>
> Moving this to a new thread, because I want to hear gstein and
> jerenkrantz argue with me. :-) ;-)
>
> I've already committed a new design for commits, which is basically a
> less noisy version of the way we already do them: a bunch of PUT
> requests. But I've heard others argue they'd much rather see commits
> happen in a single request.
>
> Arguments for the multi-request technique:
>
> * opens the door for pipelined PUTs, the way ra_svn does it
> * opens the door for parallel PUTs on a slow network
>
> Arguments for the single request technique:
>
> * many fewer network turnarounds
> * parallel PUTs may currently break FSFS (and libsvn_fs_bigtable)
>
> Personally, I'm in favor of the single-request: I think it's more
> elegant and simpler to understand, and I'm skeptical that the speed
> gain from pipelined PUTs (someday) will be worth the speed-hit of all
> the extra turnarounds.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
>
---------------------------------------------------------------------
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-10 16:36:38 CET