[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN Performance Focus

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Sun, 16 May 2010 12:49:11 +0200

Geoff Rowell <geoff.rowell_at_gmail.com
<mailto:geoff.rowell_at_gmail.com?Subject=Re:%20SVN%20Performance%20Focus>>
wrote:
>
> I think it's great that the development team has been looking into 1.7
> performance, but I must admit I'm less interested in server
> performance than that of the client. My recent experiences with huge
> working copy folders has pointed out significant disparities in
> performance under different operating and file systems. Meaningful SVN
> performance testing should take into account the majority of popular
> operating and file systems.
>
SVN uses the same libraries for basic services on the client
as it does on the server. Most of my optimization so far happen
focus on these parts:

* zlib (diff & un-diff, network data compression etc.)
* apr (windows file I/O)
* apr util (MD5 checksumming)
* svn-internal file I/O overhead

And, as Greg already said, the client-side is undergoing
a major rewrite. That is also why I concentrate on the
server-side: it is stable ground and I'm less likely to
optimize temporary artifacts.

> My corporate experience indicates that hardware upgrades are usually
> better tied to budgetary cycles and operating system upgrades.
>
>
But that is actually a perfect fit: SVN can be treated as a
"set-up-and-forget" server. New SW versions will often
at least suggest client updates etc. IOW, it requires a certain
amount of coordination and previous testing. As a result,
the server SW will be upgraded at most once during the
HW lifecycle.

So, if you are planning to roll out a new server version,
you can also take the opportunity to configure the HW
according to your needs. Some guideline can be found
in my recent post:

http://svn.haxx.se/dev/archive-2010-05/0247.shtml

-- Stefan^2.
Received on 2010-05-16 12:50:07 CEST

This is an archived mail posted to the Subversion Dev mailing list.