Re: svn ci performance issue with 1.7.x and nfs mounted working copies

Here are some quick benchmarks with our environment of the improvement the patch provides.

           1.7.4 1.7.4-patch
svn co 8m24s 4m8s
svn st 13.3s 3.2s
svn ci 1m31s 4.1s
svn rm * 1.85s 6.3s
svn revert 46.6s 4.0s

Seems to me that the default behavior should be to enable excusive locking when the sqlite database is on an nfs filesystem (i.e. stat -fc%T .) and to disable it when the system is local. The exclusive locking on nfs "could" be disabled through the config file, but I think the performance data shows that you would always want to use exclusive when you're on nfs.

"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
Michael Rytting
Agilent Technologies
michael_rytting_at_agilent.com<mailto:michael_rytting_at_agilent.com>
719-590-3708