> -----Original Message-----
> From: Stefan Fuhrmann [mailto:stefanfuhrmann_at_alice-dsl.de]
> Sent: woensdag 12 mei 2010 12:25
> To: dev_at_apr.apache.org
> Subject: First SVN performance data
>
> Hi there,
>
> as I promised, I'm going to conduct some in-depth analysis and
> comprehensive SVN performance testing.
> That is very time-consuming process.
I think this belongs on dev_at_subversion instead of dev_at_apr; moving to that
list.
>
> However, it seems that many people have incorrect or outdated ideas about
> the current state of affairs.
> To add a bit more substance to the discussion, I like to present some
> preliminary data and not to wait until I collected all data I intend to.
>
> Side note: Maybe, these numbers make it clearer why my patches should be
> committed after review.
>
> Bottom line:
> * SVN servers tend to be CPU-limited
> (we already observed that problem @ our company
> with SVN 1.4)
> * packed repositories are ~20% faster than non-packed,
> non-sharded
> * optimal file cache size is roughly /trunk size
> (plus branch diffs, but that is yet to be quantified)
> * "cold" I/O from a low-latency source takes 2 .. 3 times
> as long as from cached data
> * a fully patched 1.7 server is twice as fast as 1.6.9
>
> "Export" has been chosen to eliminate problems with client-side w/c
> performance.
Note that this also eliminates delta transfers, which are very common in
these wc operations. Subversion tries to optimize transfers by only
transferring binary updates, but you eliminated that.
I would assume that transferring full files as deltas is not the most
efficient way to transfer these full files. No surprises there. (And
transferring deltas will hopefully be faster too after this work)
In the performance measurements I did just before releasing 1.6 (on
checkout, update, merge) I found that most time was spend on client-io in
the working copy and on locking, but all of this was removed from your
testset as you are only testing the subversion fs (filesystem) and IO
performance.
While I'm certain that these components can use more than a bit of
optimization to enhance the scalability of Subversion, I'm not sure if these
are the true performance problems of subversion as noted in our user
feedback.
If you are looking at just 'svn export' you completely eliminate the
reporting phase from an update editor (the client->server reporting), which
is one of the major components of svn update and svn status --update. You
just leave the server->client data transfer, the in-memory property handling
and writing out the possibly translated files on the client.
Michael Pilato and Hyrum Wright interviewed some enterprise users earlier
this year and wrote some reports which indicated that the network latency
and working copy performance were the true bottlenecks. If I look at
^/subversion/trunk/notes/feedback, I see checkout, log, merging as primary
performance issues and this matches the performance issues I see in my day
to day use of repositories on the other side of the world. Theoretically svn
checkout should be pretty similar to the svn export your testing, but
Subversion completely implements this as updating from r0 to the specified
revision. Most of the time on these operations is spend on the client
waiting for disk (libsvn_wc administration, moving and rewriting files) and
on network-IO caused by latency (not by throughput).
(On the Slik Windows buildbot, which runs all tests on a NTFS ramdrive, I
see that the tests are CPU bound these days... But that is after eliminating
all disk IO during the tests. When I run them on a normal workstation disk I
see different results)
> Please note that all measurements were taken in a true client/server
setup.
> You can achieve similar performance in low-latency broad-band networks.
Bert
>
> -- Stefan^2.
Received on 2010-05-13 16:32:16 CEST