"Moe, Mark" <mark.moe_at_medtronic.com> writes:
> Yes, I tried it and it was very effective! See below:
>
> 1.6.17 1.7.4 1.7.4-patched
> NFS benchmark* 1534s 4074s 572s
> Local benchmark* 365s 162s 118s
> NFS svn co 29s 163s 18s
> Local svn co 4s 4s 3s
>
> Are there any downsides to this patch? It sounds like the only
> downside is a delay to simultaneous read operations for the same
> working-copy. Those operations are very rare for compared to the huge
> gains in NFS working-copy performance.
It probably rare in a Unix command line environment. GUI environments
are more difficult, it's not hard to imagine GUIs that run status to
update one window while update runs in another, and those windows could
show the same working copy. I don't know whether the current GUIs do
behave that way since the current concurrency isn't perfect: run status
during update and if a work-queue item exists then status will fail.
The other question is how well locking works on NFS. If we add this
feature will it break existing setups? Is exclusive locking more or less
reliable than the current locking? My guess is that exclusive locking is
already part of the current system and so exclusive locking is at least
as reliable as the current system.
> * The benchmark command runs a variety of svn commands and is from here https://ctf.open.collab.net/sf/wiki/do/viewPage/projects.csvn/wiki/BenchmarkInstructions.
I know it works on test case benchmarks, I'm more interested in numbers
from a real use cases. However, it is good to know that it works on
systems other than my own NFS setup.
I don't really know how to proceed. The performance gains are huge
on NFS and it's hard to see any other way to fix the 1.7 regression.
We could sacrifice concurrency for performance and enable it all the
time, essentially deciding that this is the way that WCNG will use
SQLite.
I suppose we could try to enable it automatically if appropriate, but I
don't know what test we use to make the decision. The alternative is to
make it user controllable via .subversion/config but there is opposition
to adding such controls. That raises the questions what is the default
and what do we recommend people use?
--
Philip
Received on 2012-05-01 18:14:07 CEST