On 2/7/14, 1:28 PM, Bob Archer wrote: > We switched from svn:// to http:// and didn't see any pref difference. Then > again, I didn't benchmark it. That said, we don't do any path based > authorization and that may be the difference.
svnserve will be faster if you're committing a lot of files. DAV splits your commit up into multiple PUTs and then has to wait for the server to say that each PUT has succeeded before continuing. The svnserve protocol once it goes into an edit drive just streams the changes to the server and the server only responds if there's an error or the edit drive is finished. Neither of these protocols can use parallelism with sending commits at current since the filesystem backend can't handle it. But once we resolve this DAV should be able to support this which will help lower this cost since multiple round trips can be made at the same time. DAV with more recent versions of Subversion on the client and server side may be faster than svnserve due to skelta mode on checkout, update, switch and diff. In the past DAV would send a report which included the structure and content of the files. With skelta mode DAV will send the structure (and possibly properties) but leave the content to separate GET requests. The Subversion client can make multiple GET requests at the same time, resulting in parallel downloads. If the server can't saturate your network this may result in faster downloads. Additionally, if you're far away from the server these GET requests can be cached unlike the REPORT requests which really could not be. The svn protocol is still sending file content as a single stream and can't parallelize the downloads nor is there any sort of caching capability. There's more info on skelta mode in the 1.8 release notes: https://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default Depending on your network environment your mileage may vary. If you really want to know what's faster then you'll need to try it. If you're very close to the server (thus having low latency) you may not notice much difference at all. As Bob has already said there really is nothing stopping you from running both. However, there is one big reason that nobody has mentioned. If you want to get great performance out of the server and you don't have trivial small repositories you should be configuring the memory cache. httpd and svnserve can share a cache if you use memcache, but I believe you'll have better luck if you just use a per process memory cache that can't be shared between servers. You can find some details on this from the 1.7 release notes: https://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning One major piece of advice is if you are running httpd, use a threaded MPM (worker or event) as opposed to the prefork MPM. The threaded MPMs will use fewer processes and thus you'll be able to configure a larger cache and since all threads under the same process can share that cache you'll have higher hit rates.