Re: Performance of "svn lock *"

On 17.12.2013 13:48, Philip Martin wrote:
> One of WANdisco's customers brought the performance of "svn lock *" to
> my attention. There is a network issue over HTTP and a filesystem issue
> in the repository.

My gut feeling is to just forget it. If someone wants to lock the whole
working copy, they can deal with the performance penalty as well.

> When locking multiple files over HTTP the client sends a separate LOCK
> request for each file and the round trip delays add up. Also the
> bandwidth overhead, all the HTTP headers, is high: using one request per
> path it is not an efficient way to transport paths.
>
> On the repository side creating or removing a lock involves writing an
> index file for each parent directory in addition to handling the lock
> file itself. To lock N separate files in a directory '/A/B/C' involves
> writing N times the index files for '/', '/A', '/A/B' and '/A/B/C' as
> well as handling the N lock files. To lock N files at depth D we do
> O(N*D) writes but only modify O(N+D) distinct files; it doesn't scale
> very well.

I don't understand what the index file is for ... could this be
something we could just stop writing? And what about backwards compat?

> We already pass multiple paths into svn_ra_lock so we could address part
> of the network problem by rewriting some serf code to make it pipeline
> the LOCK requests. That would have the advantage of working with older
> servers but to solve all the problems we need to make HTTP more like the
> svn protocol: send a single request (perhaps POST instead of LOCK?) for
> the repository root and pass all the paths in the body of the request.

I can't see us using POST instead of LOCK. AFAIU that's in conflict with
the DAV spec; we already know that we could have writen a much more
efficient custom HTTP protocol, and decided against it for good reasons.
Pipelining LOCK requests sounds like the way to go; people can upgrade
their servers if they really want this.

I'll skip the rest as it relies on us deciding to actually find this
scenario important.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com