Hi all,
Getting back to this oldish thread ...
I have re-analyzed my old test figures, and done some additional
tests. It seems I was mistaken with some of my conclusions (pointing
to I/O instead of CPU), so apologies to Stefan^2 and others for
"wasted cycles" in this discussion. I see now that y
Hi all,
answering several replies to my OP:
Bert Huijben wrote:
-Original Message-
From: Stefan Fuhrmann [mailto:stefanfuhrm...@alice-dsl.de]
Sent: woensdag 12 mei 2010 12:25
To: d...@apr.apache.org
Subject: First SVN performance data
Hi there,
as I promised, I'm going to co
On Wed, May 12, 2010 at 8:07 PM, Stefan Fuhrmann
wrote:
> Bottom line:
> * SVN servers tend to be CPU-limited
> (we already observed that problem @ our company
> with SVN 1.4)
Like Andrew Bolstridge said, if you have superfast I/O like you do in
your test setup (4 SSD's in RAID-0), I suppose it
> -Original Message-
> From: Stefan Fuhrmann [mailto:stefanfuhrm...@alice-dsl.de]
> Sent: woensdag 12 mei 2010 12:25
> To: d...@apr.apache.org
> Subject: First SVN performance data
>
> Hi there,
>
> as I promised, I'm going to conduct some in-depth
> -Original Message-
> From: Stefan Fuhrmann [mailto:stefanfuhrm...@alice-dsl.de]
> Sent: Wednesday, May 12, 2010 7:08 PM
> To: dev@subversion.apache.org
> Subject: First SVN performance data
>
> Hi there,
>
> as I promised, I'm going to conduct some in-de
Hi,
i've tested the load performance of SVN (svnadmin load) to load a really
large repository.
I have loaded the Apache Software Foundation Repository as dump File.
I have downloaded the svn-asf-public-r0:930176.7z (10,430,991,745 Bytes)
which decompresses to 31,492,319,472 Bytes dump file.
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.
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 discussi
7 matches
Mail list logo