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.
Received on 2014-02-08 07:02:37 CET