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

On Mon, Nov 10, 2008 at 10:53 AM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:

> Good point, your last one.
>
> Another advantage of a single request is that it means we can use the
> 'standard' commit editor that the other layers use, and give us more
> consistent semantics. (I think this was glasser's request).
>
> Let me revise the lists, leaving out the parallel PUTs, since we have
> no plans for that anytime soon.
>
> Multi-request motivations:
>
> * opens the door for pipelined writes, the way ra_svn does it
> * more resilient on a flaky network
> * more detailed logging
> * don't need to change much code
>
> Single-request motivations:
>
> * one request means less traffic overall
> * can use standard libsvn_repos commit-editor
>
> Hmmm. Maybe multi-request *is* more advantageous. Let's let this
> thread sit around for 24 hours and see if people raise other points.

Would one scale better on the server? There are a lot of Subversion
hosting services out there. If commits are performing multiple
requests on the server does that create a scalability problem? The
amount of work/data seems pretty similar, but I am wondering about the
increase in number of connections as well as any extra work the server
has to do to handle the requests and manage the transaction.

This is more a question than a statement. Would the scalability of
the server likely be impacted by this decision, and if so, to what
degree?

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org