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. br...@wandisco.com
