> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: maandag 25 juni 2012 17:24
> To: dev_at_subversion.apache.org
> Subject: Re: [Issue 4176] wcng slow on network disks
>
> markphip_at_tigris.org writes:
>
> > http://subversion.tigris.org/issues/show_bug.cgi?id=4176
>
> > I think we need to find a way to include this patch. I would suggest
> > a new runtime configuration option or an environment variable.
> > Something like "Allow concurrent client access".
>
> There are problems with the patch. One is that it is incompatible with
> the legacy access baton API, so an application using that API will need
> to have exclusive locking disabled. Another problem is the current
> implementaion results long-lived SQLite handles so programs using the
> newer API run into problems if with multiple/long-lived contexts.
>
> I think the solution is to default to non-exclusive locking and to allow
> an application to ask for exclusive locking. Then the command line
> client can be patched to ask for exclusive locking. And we provide a
> config option that allows the user to prevent the command line client
> for asking for exclusive locking so that anyone who relies on the
> existing 1.7 behaviour can still get it.
I don't think this should be the default for any client.
If we make it the default for 'svn' we can just start calling it Subversion
2.0 as it breaks all the existing multi client behavior.
I don't see a problem with adding a '--exclusive' option or something (or
adding it to the config usable via --config-option), or whatever but I don't
think we should make it default on any platform.
Making it default in our testsuite is just as bad as just creating a much
simpler exclusive working copy format. Why bother with using a sql backend
if there can be only a single user?
The problem is/was that Subversion is slow on NFS.
As far as I can tell we never intended it to be fast on that filesystem. The
locks make us slower, especially on NFS and in some ways Unix, while on
Windows we always had locks. (The unix folks just didn't care. Just like
Apache Httpd currently doesn't care about some really slow code on Windows
right now).
My guess is that the reactions today are triggered by the slow query problem
on users_at_s.a.o.
This query had a ?2 = '' check which made us perform a full table scan
before I fixed all those cases for 1.8.
So making this call exclusive as suggested by issue #4176 would still make
us read the entire 1.5 GB database over NFS (which I assume is mostly filled
by NODES), while the proper query fix just makes us read the index and a
single row.
Assuming 100 Mbit the delete is probably back to something like 15-30
minutes by making it exclusive and to something like 1-3 seconds (but could
be a fraction of a second) with the query fix and a recent Sqlite.
The exclusive fix might optimize it a bit further, but at a considerable
compatibility cost. The million to one fix is in using the index.
Bert
Received on 2012-06-25 17:35:37 CEST