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

Re: http protocol very slow for moderate-sized data sets

From: Anders J. Munch <ajm_at_flonidan.dk>
Date: 2005-04-28 17:02:38 CEST

From: Chermside, Michael [mailto:mchermside@ingdirect.com]
> > > Question 2: Are these timings reasonable? Is subversion
> this slow?
>
> > 1-5 MB/s is slow to you? You must have one heck of a workstation.
>
> Well actually, yes. We're intending for it to support ~20 developers
> and about 40 other people who do less frequent checkouts of
> configuration data and occasional updates.

I guess we can take for granted that the most important bottleneck for
you will be server-side. However, the bottleneck you experienced in
your tests may well have been client-side. That's where the
duplication and lots-of-little-files are. Server-side, the BerkeleyDB
backend may be faster for your purposes than FSFS, especially for
checking out HEAD (due to "reverse deltification"). In theory,
anyway, I have absolutely NO practical experience and NO measurements
to back it up. Also note, people on this list seem to have some
reservation about BDB stability, I don't know how seriously to take
that.

>And we expect an automated
> server to be doing clean checkouts, builds, and unit tests on a
> frequent basis (hourly, or perhaps triggered by checkins).
> Unfortunately, most of my scaling estimates had been done using
> svnserve, and I had not expected such a dramatic difference.

Here's a thought: If you run a script to delete all non-versioned
files from a working copy, and follow it by an update or switch, the
result should be identical to a fresh checkout. Writing such a script
is quite easy using for example pysvn.

To convince the paranoid that this is good enough, once every X builds
do a clean checkout to a separate location and compare the clean
checkout to the incremental.

A similar approach would be to use update, but copy the working copy
to a different location before build, thus not polluting the working
copy with build artifacts, for the same effect.

> > If the bottleneck is the local file system, strive to use a modern
> > file system that deals well with lots of small files. Microsoft FSs
> > are said to be bad at this.
>
> Now that might well be an issue, this IS running on an NTFS
> file system.
> There IS some possibility of running a unix OS if we know it will
> improve performance significantly.

If anyone on this list has done actual measurements on BDB vs. FSFS or
NFTS vs. extX, now would be a good time to chime in.

- Anders

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 28 18:08:09 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.