Re: AW: SQLite locking for WCNG on NFS

On Wed, Feb 22, 2012 at 7:30 AM, Simon Butler <smcbutler_at_gmail.com> wrote:
>
>
> On Wed, Feb 22, 2012 at 1:25 AM, Philip Martin <philip.martin_at_wandisco.com>
> wrote:
>>
>> Branko ÄŒibej <brane_at_apache.org> writes:
>>
>> > On 20.02.2012 09:51, Markus Schaber wrote:
>> >> Hi,
>> >>
>> >> What about an "-exclusive" general option to the svn command line
>> >> client, which triggers exclusive wc access for that specific command
>> >> invocation / session?
>> >
>> > And you expect users to know when to use it, and especially when /not/
>> > to use it?
>> >
>> > Come now. Controlling performance tweaks from the user interface is
>> > hardly good design.
>>
>> Not sure I agree,  I don't see how anything other than the user can make
>> the choice.
>>
>> The user has more information than the application can ever have.  If
>> the user wants to be able to run two subtree updates in parallel then
>> exlusive locking must not be enabled.  If the user wants to run status
>> during an update then exclusive locking must not be enabled.  If the
>> user is happy with one process having exclusive access then exclusive
>> locking is a major performance gain.  If the user isn't making that
>> decision how else can it be made?
>>
>> The performance gains on NFS are large.  I import Subversion trunk into
>> a repository to use as my dataset.  I checkout, run status, modify a
>> single file, commit, run update.  This is on my Linux-Linux NFS setup,
>> which isn't fast but has no other users.
>>
>>               without         with
>>               exclusive       exclusive
>>
>>   checkout:   2m33s           53s
>> status cold:      3.6s          1.3s
>>  status hot:      2.6s          0.4s
>>     commit:     35s            3s
>>     update:      4s            0.9s
>>
>> It's hard to ignore performance gains that are so big.
>>
>> We could completely rewrite the commit harvester to use queries more
>> suited to the single db.  That might be faster but I don't know whether
>> it would it would get us the order of magnitude gain that exclusive
>> locking provides.  It's a non-trivial amount of code.
>>
>> I suppose we might be able to make status into a single query, but like
>> commit that's a major bit of code to be rewritten.  It's certainly not
>> going to happen in 1.7, I suppose it might happen in 1.8.
>>
>
> We would also prefer exclusive locking in our workflow and it would be great
> if we could program-in this kind of optimization in the client. I'm guessing
> there will others like this so why not have an "optimize" of similar switch
> that can take a  list of settings (including exclusive=t)?

Are you just saying you want the performance increase it brings? I am
having trouble understanding why anyone would WANT exclusive locking
independent of the performance gain.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/