Re: HTTP protocol v2: single commit request, or many PUTs?

On Mon, Nov 10, 2008 at 6:28 PM, 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.
>
I'm in favor of the single-request too: IMHO biggest advantage of HTTP
v2 is simplicity. Single request is easier to code, debug and
understand.

On other hand pipelined PUTs can be potentially faster: data can be
send in binary format instead of encoding it to xml.

-- 
Ivan Zhakov
VisualSVN Team
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org