Ben Collins-Sussman wrote:
>On Thu, 2004-04-15 at 11:32, Keven Ring wrote:
>
>
>
>>Has anyone seen performance issues such as these?
>>
>>
>
>Keven actually mailed me privately about this stuff, before I asked him
>to post this mail to the dev list. My comments were:
>
> * Hm, this looks like what we saw last summer, before we did the huge
>speed improvements in the fall. But after the improvements, checkouts
>were very, very close in speed to CVS. (Did anyone notice that since
>the 1.0 release, we've had no speed complaints? That's a big deal in my
>mind!)
>
> * I would expect svn imports to be slower than cvs, if only because
>the client *and* server are both doing compression. A fairer test might
>be to run 'cvs -z9'. But imports are generally one-time things, so the
>checkout/update timings are much important, I think.
>
> * Is anyone else seeing this sort of slowness? Might there be
>something specific about Keven's setup that's causing this?
>
>
>
I last ran my perf suite in Oct 2003 (I think right after a major
performance enhancement had been committed) and my results were similar.
http://subversion.kicks-ass.org/perf/elapsed.html
http://subversion.kicks-ass.org/svn-fs-bench/
The key thing I've gleamed from these tests is that you have Write Cache
Enabled (WCE) on your hard drives, preferrably use EXT3 or XFS for your
partitions (never got a chance to test Reiser4), hopefully use the 2.6
kernel, and have --bdb-txn-nosync enabled on your repositories to
achieve maximum performance.
I haven't formalized my results yet, but SVN running on an AMD64
architecture is also a nice performance boost. The only downside (and
reason for my results taking so long to finish) is that AMD64 driver
support is still very hard to come by.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 16 09:28:27 2004