[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: HTTP protocol v2: rethunk.

From: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 6 Nov 2008 09:04:58 -0500

On Thu, Nov 6, 2008 at 7:55 AM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> On Thu, Nov 6, 2008 at 1:35 AM, David Glasser <glasser_at_davidglasser.net> wrote:
>> There's a lock around appending to the proto-rev file, yes. And it
>> does write a bunch of little files for noderevs, directory listings,
>> and props, and gloms them on at finalization time, yes. But there are
>> no locks around editing the little files themselves; so for example,
>> if concurrent processes make two files in a directory at the same
>> time, there can be a race condition and only one will end up in the
>> listing. This situation isn't possible if you only access a
>> transaction from a single process (say, via the commit editor).
> But if all writes go through a single process, that sort of defeats
> the goal of saturating the bandwidth with parallel PUTs. Maybe it
> would be a worthy goal to make FSFS safe? I know it's something we'll
> have to do for libsvn_fs_bigtable.

Do we know that "saturating the pipe" will give the best performance?
We (CollabNet) are frequently hearing complaints of WAN performance
lately and it has been suggested that a single request would perform
better in that environment because:

a) the pipe is not that big
b) the latency on turnarounds is the biggest killer of performance

Mark Phippard
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 15:05:18 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.