You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ivan Zhakov <iv...@visualsvn.com> on 2014/06/19 12:21:58 UTC
Subversion 1.9.0-dev FSFS performance tests
Hi,
I've performed several FSFS performace tests using latest Subversion
from trunk@r1602928.
Please find results bellow. I'm also attaching results as a table in
pdf for easier reading.
Environment:
Windows Server 2012 R2 (x64)
2 GB RAM, with 2 virtual processors hosted on Macbook with SSD disk
Subversion 1.9.0-dev from trunk@r1602928
Test data: Ruby project repository (46054 revisions, 400mb-500mb size on disk)
All tests are performed using default options.
Tests performed:
1. svnadmin load -- loading first 5000 revisions into repository
2. svnadmin dump -- dumping all repository revions to NUL
3. svn log http:// -- svn log over http:// protocol to NUL
4. svn log file:// -- svn log over file:// protocol to NUL
5. svn export http:// -- svn export over http:// protocol to local disk
6. svn export file:// -- svn export over file:// protocol to local disk
Subversion 1.9.0-dev, fsfs7 unpacked repository
===============================================
svnadmin load 231.035 220.538 182.104
svnadmin dump 657.378 648.268 524.209
svn log http:// 56.323 56.166 58.141
svn log file:// 4.999 2.814 3.415
svn export http:// 99.028 94.531 119.954
svn export file:// 20.305 8.052 8.507
Subversion 1.9.0-dev, fsfs6 unpacked repository
===============================================
svnadmin load 156.095 167.769 146.140
svnadmin dump 539.622 524.209 500.438
svn log http:// 11.271 9.442 9.016
svn log file:// 3.085 3.352 3.097
svn export http:// 7.336 7.757 7.437
svn export file:// 4.151 4.854 4.310
Subversion 1.9.0-dev, fsfs7 packed repository
===============================================
svnadmin dump 1286.137 1220.515 1297.122
svn log http:// 49.561 51.405 49.965
svn log file:// 48.637 47.470 54.862
svn export http:// !!! TIMEOUT !!!!
svn export file:// 33.033 26.485 25.703
Subversion 1.9.0-dev, fsfs6 packed repository
===============================================
svnadmin dump 743.673 652.682 653.692
svn log http:// 57.641 55.789 53.633
svn log file:// 52.088 47.752 48.577
svn export http:// 16.517 10.635 10.909
svn export file:// 6.049 7.997 7.671
--
Ivan Zhakov
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Ivan Zhakov <iv...@visualsvn.com>.
> Can you guys dig a little bit deeper here? Seems the performance
> regression that Ivan is seeing deserves some more investigation. With
> Ivan testing http: (and file:) on Windows, and Stefan testing svn: on
> Linux (with different cache settings) it's hard to see where the
> regression comes from.
There are the following main factors that lead to performance regressions:
* log addressing adds two additional files for each revision file
(that is obviously not good for unpacked repositories),
* the whole design relies on the enormous cache size (comparable to
the size of the repository itself).
> Right now, the numbers might just as well indicate that f7 is fast on
> Linux but slow on Windows. Or that it's only fast with svn: but slow
> with http:. That would be "not good".
The numbers do not depend on operating system so much. Stefan Sperling
has results that shows performance degradation on OpenBSD too. From
what I see,
FSFS7 may be fast when repository is packed and there is an enormous
cache size. It is slow when repository is unpacked (default) and cache
size if adequate (default).
--
Ivan Zhakov
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Jun 19, 2014 at 5:06 PM, Stefan Fuhrmann
<st...@wandisco.com> wrote:
>
> Turn out that the ruby repo is something special
> in that it has very deep histories of relatively few,
> very small files combined with one huge changelog
> file (the latter taking up ~75% of the repo). See
> below for details.
>
> Also, please note that your exports contained
> >500000 files. Using 16MB of cache with that
> project size *may* not be an adequate setup.
> Upping that to insane 256MB (roughly what 1.6
> would use anyway), gives much better numbers.
> However, there is hardly a difference between
> f6 and f7 in these runs.
>
> Here my measurements with svn: under Linux:
>
> null-export svn://localhost/ruby/trunk
> 461 directories
> 4,263 files
> 48,880,945 bytes in files
> 23,783 properties
> 324,660 bytes in properties
>
> F7 packed 20.249s, all default
> F6 packed 20.168s, all default
>
> F7 packed 14.310s, 256MB cache
> F6 packed 15.167s, 256MB cache
>
> F7 packed 13.649s, 256MB cache -c 0
> F6 packed 14.226s, 256MB cache -c 0
>
> F7 packed 13.478s, 256MB cache -c 0 --cache-revprops yes
> F6 packed 13.223s, 256MB cache -c 0 --cache-revprops yes
>
> export svn://localhost/ruby/
> 54,641 directories
> 512,580 files
> 4,558,565,078 bytes in files
> 3,077,645 properties
> 45,809,954 bytes in properties
>
> F7 packed 763.520s, all default
> F6 packed 785.913s, all default
>
> F7 packed 153.520s, 256MB cache
> F6 packed 152.746s, 256MB cache
>
> F7 packed 64.695s, 256MB cache -c 0
> F6 packed 65.505s, 256MB cache -c 0
>
> F7 packed 55.534s, 256MB cache -c 0 --cache-revprops yes
> F6 packed 56.697s, 256MB cache -c 0 --cache-revprops yes
>
> null-log svn://localhost/ruby/
> 46,054 revisions
> 177,176 msg lines
> 0 changes
>
> F7 packed 58.494s, all defaults
> F6 packed 58.852s, all defaults
>
> F7 packed 2.153s, --cache-revprops yes
> F6 packed 2.470s, --cache-revprops yes
>
Can you guys dig a little bit deeper here? Seems the performance
regression that Ivan is seeing deserves some more investigation. With
Ivan testing http: (and file:) on Windows, and Stefan testing svn: on
Linux (with different cache settings) it's hard to see where the
regression comes from.
Maybe Ivan can retest with different cache settings (256MB etc), so we
at least know that it *can* be performant with http: on Windows? Or
maybe Stefan can do more benchmarks with http: (on Linux and on
Windows)?
Right now, the numbers might just as well indicate that f7 is fast on
Linux but slow on Windows. Or that it's only fast with svn: but slow
with http:. That would be "not good".
If f7 is all about better performance, there should be virtually no
performance regressions (especially not for setups with "default
configurations"):
- Whether it's the ruby or the FreeBSD repo.
- Whether it's svn: or http:.
- Whether it's hosted on Linux or on Windows.
- ...
--
Johan
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Jun 19, 2014 at 11:38 PM, Branko Čibej <br...@wandisco.com> wrote:
> On 19.06.2014 17:06, Stefan Fuhrmann wrote:
>
> Turn out that the ruby repo is something special
> in that it has very deep histories of relatively few,
> very small files combined with one huge changelog
> file (the latter taking up ~75% of the repo). See
> below for details.
>
> Also, please note that your exports contained
> >500000 files. Using 16MB of cache with that
> project size *may* not be an adequate setup.
> Upping that to insane 256MB (roughly what 1.6
> would use anyway), gives much better numbers.
> However, there is hardly a difference between
> f6 and f7 in these runs.
>
>
>
> Heh, this sound suspiciously like saying that one has to have the right
> test data to make v7 faster than v6. :)
>
Sure. As far as I can see, we always end up reading
most of the repository in this specific case as there
are virtually no entirely cool data blocks. It's only ~40
pack files and most files seem to be present since early
in the project -> most paths need to be read from almost
all pack files.
Since the whole repo is also quite small on disk (~400MB),
everything ends up in disk cache and the reading order
is of little importance. The BSD repo OTOH, has 20x
as much data in their "trunk" ("/head") and the history
is 5x deeper. Plus lots of branching and merging and
f7 reorg-on-pack helps quite a bit.
-- Stefan^2.
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Branko Čibej <br...@wandisco.com>.
On 19.06.2014 17:06, Stefan Fuhrmann wrote:
> Turn out that the ruby repo is something special
> in that it has very deep histories of relatively few,
> very small files combined with one huge changelog
> file (the latter taking up ~75% of the repo). See
> below for details.
>
> Also, please note that your exports contained
> >500000 files. Using 16MB of cache with that
> project size *may* not be an adequate setup.
> Upping that to insane 256MB (roughly what 1.6
> would use anyway), gives much better numbers.
> However, there is hardly a difference between
> f6 and f7 in these runs.
Heh, this sound suspiciously like saying that one has to have the right
test data to make v7 faster than v6. :)
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Sat, Jun 21, 2014 at 5:18 PM, Branko Čibej <br...@wandisco.com> wrote:
> On 20.06.2014 11:22, Ivan Zhakov wrote:
>
> On 19 June 2014 17:06, Stefan Fuhrmann <st...@wandisco.com> <st...@wandisco.com> wrote:
>
> Turn out that the ruby repo is something special
> in that it has very deep histories of relatively few,
> very small files combined with one huge changelog
> file (the latter taking up ~75% of the repo). See
> below for details.
>
> Also, please note that your exports contained
>
> 500000 files. Using 16MB of cache with that
>
> project size *may* not be an adequate setup.
> Upping that to insane 256MB (roughly what 1.6
> would use anyway), gives much better numbers.
> However, there is hardly a difference between
> f6 and f7 in these runs.
>
>
I made this statement before Ivan disclosed what commands he actually ran.
Having 256MB of cache is at least worth a try when dealing with 4GB
checkouts.
I provided the "all defaults" setting as well, so everyone can see how
caching
inside SVN *does* speed things up - an effect that Ivan adamantly denied
exists.
> Here my measurements with svn: under Linux:
>
>
> There is still misleading information about real fsfs7 performance:
> 1. You're comparing fsfs7 packed vs fsfs6 packed and do not provide
> data for fsfs6/fsfs7 unpacked. I already demonstrated you that fsfs6
> unpacked (default) is dramatically faster with defaults options.
>
>
As you can see from the numbers I posted above, packed f7
is not worse than packed f6 even with default settings. Hence,
your statement of "relies on huge caches" has been demonstrated
to be false.
It is true however, that f7 will use caches more eagerly and its
design makes it benefit from moderate cache sizes (.1-1G) more
than f6. Actual gains depend on circumstances, of course.
> 2. You're still testing svn:// protocol only. And you even don't
> bother to test http:// protocol, while I demonstrated you 10 times
> performance degradation on the same test data.
>
> Setting up the HTTP test simply takes me a while. But I will
do it. In a real-world setup, HTTP should deliver data twice
as fast as svn: for exports from cold disks, simply because it
issues concurrent requests and keeps more heads busy.
Also I don't see anything special with repositories with deep
> histories: that's pretty typical for source code.
>
>
> I have to agree with Ivan on the topic of comparing performance
> measurements. Let's try to get rid of observer bias here, please.
>
It's not so much about bias as it is about the time required to
do it. Ivan is using SSDs, I'm using a spinning disk for the tests.
Also, I decided on Friday that I should spend time on understanding
and fixing the issues rather than waiting for even more tests to
complete.
I turned out that the cause of the packed ./. non-packed regression
was a simple change in the 1.9 repo defaults. With r1604414,
packed repositories are now faster than non-packed on everything
with higher I/O latency than a RAM disk (they become CPU bound
on RAM disks). With r1604421, non-packed f7 is no longer more
I/O intensive than non-packed f6.
So, the root causes that we identified for the performance problems
have been addressed now and (re-)testing makes sense. However,
during my root cause analysis, I realized how "naturally grown",
imported and copied repos are very different in their I/O characteristics.
I'll write a post on that shortly.
FWIW. below there are the results from what I did at the office
on Friday. Non-packed repos are entirely I/O bound on spinning
disks with caching hardly making a difference. file:// is slightly
faster than svn:// do to missing protocol overhead. Log is faster
on non-packed repos due to the issue fixed in r1604414.
-- Stefan^2.
time svn-bench null-export $ruby/trunk
F7 non-packed 287.834s, 256MB cache -c 0, svn://
F6 non-packed 244.710s, 256MB cache -c 0, svn://
F7 non-packed 290.476s, all defaults, svn://
F6 non-packed 251.506s, all defaults, svn://
F7 non-packed 287.806s, all defaults file://
F6 non-packed 244.394s, all defaults file://
F7 packed 14.573s, all defaults file://
F6 packed 15.014s, all defaults file://
time svn-bench null-log $ruby/
F6 non-packed 19.615s, all defaults, svn://
F7 non-packed 20.223s, all defaults, svn://
F6 non-packed 17.358s, all defaults file://
F7 non-packed 19.148s, all defaults file://
F6 packed 59.090s, all defaults file://
F7 packed 56.439s, all defaults file://
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Branko Čibej <br...@wandisco.com>.
On 21.06.2014 17:18, Branko Čibej wrote:
> On 20.06.2014 11:22, Ivan Zhakov wrote:
>> On 19 June 2014 17:06, Stefan Fuhrmann <st...@wandisco.com> wrote:
>>> Turn out that the ruby repo is something special
>>> in that it has very deep histories of relatively few,
>>> very small files combined with one huge changelog
>>> file (the latter taking up ~75% of the repo). See
>>> below for details.
>>>
>>> Also, please note that your exports contained
>>>> 500000 files. Using 16MB of cache with that
>>> project size *may* not be an adequate setup.
>>> Upping that to insane 256MB (roughly what 1.6
>>> would use anyway), gives much better numbers.
>>> However, there is hardly a difference between
>>> f6 and f7 in these runs.
>>>
>>> Here my measurements with svn: under Linux:
>>>
>> There is still misleading information about real fsfs7 performance:
>> 1. You're comparing fsfs7 packed vs fsfs6 packed and do not provide
>> data for fsfs6/fsfs7 unpacked. I already demonstrated you that fsfs6
>> unpacked (default) is dramatically faster with defaults options.
>>
>> 2. You're still testing svn:// protocol only. And you even don't
>> bother to test http:// protocol, while I demonstrated you 10 times
>> performance degradation on the same test data.
>>
>> Also I don't see anything special with repositories with deep
>> histories: that's pretty typical for source code.
>
> I have to agree with Ivan on the topic of comparing performance
> measurements. Let's try to get rid of observer bias here, please.
Ah, actually we're seeing confirmation bias, not observer bias ... yet. :)
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Branko Čibej <br...@wandisco.com>.
On 20.06.2014 11:22, Ivan Zhakov wrote:
> On 19 June 2014 17:06, Stefan Fuhrmann <st...@wandisco.com> wrote:
>> Turn out that the ruby repo is something special
>> in that it has very deep histories of relatively few,
>> very small files combined with one huge changelog
>> file (the latter taking up ~75% of the repo). See
>> below for details.
>>
>> Also, please note that your exports contained
>>> 500000 files. Using 16MB of cache with that
>> project size *may* not be an adequate setup.
>> Upping that to insane 256MB (roughly what 1.6
>> would use anyway), gives much better numbers.
>> However, there is hardly a difference between
>> f6 and f7 in these runs.
>>
>> Here my measurements with svn: under Linux:
>>
> There is still misleading information about real fsfs7 performance:
> 1. You're comparing fsfs7 packed vs fsfs6 packed and do not provide
> data for fsfs6/fsfs7 unpacked. I already demonstrated you that fsfs6
> unpacked (default) is dramatically faster with defaults options.
>
> 2. You're still testing svn:// protocol only. And you even don't
> bother to test http:// protocol, while I demonstrated you 10 times
> performance degradation on the same test data.
>
> Also I don't see anything special with repositories with deep
> histories: that's pretty typical for source code.
I have to agree with Ivan on the topic of comparing performance
measurements. Let's try to get rid of observer bias here, please.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 19 June 2014 17:06, Stefan Fuhrmann <st...@wandisco.com> wrote:
> Turn out that the ruby repo is something special
> in that it has very deep histories of relatively few,
> very small files combined with one huge changelog
> file (the latter taking up ~75% of the repo). See
> below for details.
>
> Also, please note that your exports contained
>>500000 files. Using 16MB of cache with that
> project size *may* not be an adequate setup.
> Upping that to insane 256MB (roughly what 1.6
> would use anyway), gives much better numbers.
> However, there is hardly a difference between
> f6 and f7 in these runs.
>
> Here my measurements with svn: under Linux:
>
There is still misleading information about real fsfs7 performance:
1. You're comparing fsfs7 packed vs fsfs6 packed and do not provide
data for fsfs6/fsfs7 unpacked. I already demonstrated you that fsfs6
unpacked (default) is dramatically faster with defaults options.
2. You're still testing svn:// protocol only. And you even don't
bother to test http:// protocol, while I demonstrated you 10 times
performance degradation on the same test data.
Also I don't see anything special with repositories with deep
histories: that's pretty typical for source code.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Stefan Fuhrmann <st...@wandisco.com>.
Turn out that the ruby repo is something special
in that it has very deep histories of relatively few,
very small files combined with one huge changelog
file (the latter taking up ~75% of the repo). See
below for details.
Also, please note that your exports contained
>500000 files. Using 16MB of cache with that
project size *may* not be an adequate setup.
Upping that to insane 256MB (roughly what 1.6
would use anyway), gives much better numbers.
However, there is hardly a difference between
f6 and f7 in these runs.
Here my measurements with svn: under Linux:
null-export svn://localhost/ruby/trunk
461 directories
4,263 files
48,880,945 bytes in files
23,783 properties
324,660 bytes in properties
F7 packed 20.249s, all default
F6 packed 20.168s, all default
F7 packed 14.310s, 256MB cache
F6 packed 15.167s, 256MB cache
F7 packed 13.649s, 256MB cache -c 0
F6 packed 14.226s, 256MB cache -c 0
F7 packed 13.478s, 256MB cache -c 0 --cache-revprops yes
F6 packed 13.223s, 256MB cache -c 0 --cache-revprops yes
export svn://localhost/ruby/
54,641 directories
512,580 files
4,558,565,078 bytes in files
3,077,645 properties
45,809,954 bytes in properties
F7 packed 763.520s, all default
F6 packed 785.913s, all default
F7 packed 153.520s, 256MB cache
F6 packed 152.746s, 256MB cache
F7 packed 64.695s, 256MB cache -c 0
F6 packed 65.505s, 256MB cache -c 0
F7 packed 55.534s, 256MB cache -c 0 --cache-revprops yes
F6 packed 56.697s, 256MB cache -c 0 --cache-revprops yes
null-log svn://localhost/ruby/
46,054 revisions
177,176 msg lines
0 changes
F7 packed 58.494s, all defaults
F6 packed 58.852s, all defaults
F7 packed 2.153s, --cache-revprops yes
F6 packed 2.470s, --cache-revprops yes
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Stefan Fuhrmann <st...@wandisco.com>.
I'm missing a few points here:
* what were the exact commands run?
* how did you configure your server?
* did you clean disk caches between runs?
* were both, client and server, run on the same VM?
On Thu, Jun 19, 2014 at 12:21 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> Hi,
>
> I've performed several FSFS performace tests using latest Subversion
> from trunk@r1602928.
>
> Please find results bellow. I'm also attaching results as a table in
> pdf for easier reading.
>
> Environment:
> Windows Server 2012 R2 (x64)
> 2 GB RAM, with 2 virtual processors hosted on Macbook with SSD disk
> Subversion 1.9.0-dev from trunk@r1602928
> Test data: Ruby project repository (46054 revisions, 400mb-500mb size on
> disk)
>
> All tests are performed using default options.
>
> Tests performed:
> 1. svnadmin load -- loading first 5000 revisions into repository
> 2. svnadmin dump -- dumping all repository revions to NUL
> 3. svn log http:// -- svn log over http:// protocol to NUL
> 4. svn log file:// -- svn log over file:// protocol to NUL
> 5. svn export http:// -- svn export over http:// protocol to local disk
> 6. svn export file:// -- svn export over file:// protocol to local disk
>
>
> Subversion 1.9.0-dev, fsfs7 unpacked repository
> ===============================================
> svnadmin load 231.035 220.538 182.104
> svnadmin dump 657.378 648.268 524.209
> svn log http:// 56.323 56.166 58.141
> svn log file:// 4.999 2.814 3.415
> svn export http:// 99.028 94.531 119.954
> svn export file:// 20.305 8.052 8.507
>
> Subversion 1.9.0-dev, fsfs6 unpacked repository
> ===============================================
> svnadmin load 156.095 167.769 146.140
> svnadmin dump 539.622 524.209 500.438
> svn log http:// 11.271 9.442 9.016
> svn log file:// 3.085 3.352 3.097
> svn export http:// 7.336 7.757 7.437
> svn export file:// 4.151 4.854 4.310
>
> Subversion 1.9.0-dev, fsfs7 packed repository
> ===============================================
> svnadmin dump 1286.137 1220.515 1297.122
> svn log http:// 49.561 51.405 49.965
> svn log file:// 48.637 47.470 54.862
> svn export http:// !!! TIMEOUT !!!!
> svn export file:// 33.033 26.485 25.703
>
> Subversion 1.9.0-dev, fsfs6 packed repository
> ===============================================
> svnadmin dump 743.673 652.682 653.692
> svn log http:// 57.641 55.789 53.633
> svn log file:// 52.088 47.752 48.577
> svn export http:// 16.517 10.635 10.909
> svn export file:// 6.049 7.997 7.671
>
>
> --
> Ivan Zhakov
>
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 20 June 2014 12:33, Stefan Fuhrmann <st...@wandisco.com> wrote:
> On Thu, Jun 19, 2014 at 12:21 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>> Hi,
>>
>> I've performed several FSFS performace tests using latest Subversion
>> from trunk@r1602928.
>>
>> Please find results bellow. I'm also attaching results as a table in
>> pdf for easier reading.
>>
>> Environment:
>> Windows Server 2012 R2 (x64)
>> 2 GB RAM, with 2 virtual processors hosted on Macbook with SSD disk
>> Subversion 1.9.0-dev from trunk@r1602928
>> Test data: Ruby project repository (46054 revisions, 400mb-500mb size on
>> disk)
>>
>> All tests are performed using default options.
>>
>> Tests performed:
>> 1. svnadmin load -- loading first 5000 revisions into repository
>> 2. svnadmin dump -- dumping all repository revions to NUL
>> 3. svn log http:// -- svn log over http:// protocol to NUL
>> 4. svn log file:// -- svn log over file:// protocol to NUL
>> 5. svn export http:// -- svn export over http:// protocol to local disk
>> 6. svn export file:// -- svn export over file:// protocol to local disk
>>
>> Subversion 1.9.0-dev, fsfs6 unpacked repository
>> ===============================================
>
> ..
>>
>> svn export http:// 7.336 7.757 7.437
>> svn export file:// 4.151 4.854 4.310
>
>
> Did you actually run the export on the repository root?
I did run svn export only for trunk of course, but I tested svn log on
repository root.
--
Ivan Zhakov
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Jun 19, 2014 at 12:21 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> Hi,
>
> I've performed several FSFS performace tests using latest Subversion
> from trunk@r1602928.
>
> Please find results bellow. I'm also attaching results as a table in
> pdf for easier reading.
>
> Environment:
> Windows Server 2012 R2 (x64)
> 2 GB RAM, with 2 virtual processors hosted on Macbook with SSD disk
> Subversion 1.9.0-dev from trunk@r1602928
> Test data: Ruby project repository (46054 revisions, 400mb-500mb size on
> disk)
>
> All tests are performed using default options.
>
> Tests performed:
> 1. svnadmin load -- loading first 5000 revisions into repository
> 2. svnadmin dump -- dumping all repository revions to NUL
> 3. svn log http:// -- svn log over http:// protocol to NUL
> 4. svn log file:// -- svn log over file:// protocol to NUL
> 5. svn export http:// -- svn export over http:// protocol to local disk
> 6. svn export file:// -- svn export over file:// protocol to local disk
>
> Subversion 1.9.0-dev, fsfs6 unpacked repository
> ===============================================
>
..
> svn export http:// 7.336 7.757 7.437
> svn export file:// 4.151 4.854 4.310
>
Did you actually run the export on the repository root?
If so, those numbers are plainly impossible. Here is why:
54,641 directories
512,580 files
4,558,565,078 bytes in files
3,077,645 properties
45,809,954 bytes in properties
There is simply no way that httpd would deliver that amount
of data in about 4 seconds! To do this requires hot caches and
20 .. 30 GHz of CPU power being used by > 10 concurrent
connections.
Also, you are basically saying that reading many small files
is more efficient than reading the same amount of user data
combined into a few larger ones. The on-disk data size alone
should make packed repos faster.
-- Stefan^2.
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 7 July 2014 20:44, Julian Foad <ju...@btopenworld.com> wrote:
> I should probably let Stefan answer this, but...
>
> C. Michael Pilato wrote:
>>> On 07.07.2014 17:07, C. Michael Pilato wrote:
>>>> On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
>>>>> My technical opinion that FSFS7/log addressing is slower by design,
>>>>> because it's doing more (read index, then read data instead of just
>>>>> read data) and only caching makes them comparable on performance to
>>>>> FSFS6 repositories.
>
> Ivan, it sounds like you've missed the important part of the design.
> It's designed to do LESS work in total, not more, because the cost of using
> the index is outweighed by the savings that it enables. As I understand it,
> a large saving is gained by re-ordering the data on disk during packing;
> that's why packing is essentially a requirement.
It seems to be designed to do less work in total if there is enough cache at
expense of other users who don't have enough caches.
As I understand constructing final content for file in FSFS7 works like
this (Stefan2 may correct me if I wrong):
1. Open rev10 file
2. Seek to end
3. Read rev10 file trailer
4. Seek to l2p index position
5. Read page of data from l2p index, decode it from 7bit encoding
6. Store index page content in cache.
7. Lookup index to find absolute offset of text delta
8. Open rev9 file
9. Seek to end
10. Read rev10 file trailer
11. Seek to l2p index position
12. Read page of data from l2p index, decode it from 7bit encoding
13. Store index page content in cache.
14. Seek to delta offset in rev10 file
15. Seek to delta offset in rev9 file
Then read two files combining deltas to produce final content.
Steps [2-7] and [9-13] could be potentially avoid if there is enough cache, but
for other use cases it's just waste of resources.
While for FSFS6 repository looks like:
1. Open rev10 file
2. Seek to delta offset in rev10 file
3. Open rev9 file
4. Seek to delta offset in rev9 file
Then read two files combining deltas to produce final content.
Regarding re-ordering during packing: it sounds good in theory, but I
doubt this will work in real world scenarios. There several reasons:
1. There is no explicit continous read: the code still reads
data in random order and assume that OS or "block read" prefetch
(FSFS7 feature)
will deliver data faster since it's reading around the same area.
2. It doesn't help if text deltas spreads across different pack files
3. SANs, SSDs, hybrid-disk and virtual disk are very popular now and assumption
that they have spinning disks characteristcs is wrong IMHO.
---
Ivan Zhakov
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Jul 7, 2014 at 12:44 PM, Julian Foad <ju...@btopenworld.com>
wrote:
>
> C-Mike, my understanding is that F7 comprehensively beats F6 speed, by
> large factors around x1.5 and more, in the kind of scenarios it's designed
> for. Caching is an assumed part of the design. I don't know how much it
> needs for what scenarios, or what you mean by 'non-trivial' or 'ginormous',
> but probably not as much as you might be led to think. I suggest you first
> look at Stefan's recent-ish test results [1] and other recent threads.
>
> The only concerns about speed are about scenarios where it doesn't match
> F6 speed. While many scenarios are faster, some are slower, especially with
> the currently-default small cache size. Ivan reported some such scenarios
> [2].
>
> My general observation is that wider testing is needed to draw firm
> conclusions.
>
>
My feeling, which could be wrong, is that caching is of little value to me.
All of the sites I work with are using Apache. Most of them have hundreds
if not thousands of repositories. Typically all of them are being used
each day and there are thousands of users hitting the site.
I just cannot envision scenarios where caching could ever be that helpful.
Or that I could have enough RAM to make the caching useful while still
servicing hundreds of simultaneous Apache connections.
On Linux, we also use prefork MPM as that is the only one that ever seemed
stable over long periods. I am guessing that the worker MPM could be tuned
to work well but we'd run into various problems with RAM not being released
and/or incompatibility with other modules running in the server and always
went back to prefork.
FWIW, I am fine with the idea of making a repository format that can give
great performance when caching is enabled. I tend to think it should not
be our default format unless it performs just as well as what it is
replacing when cache is not being used, or is small.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Julian Foad <ju...@btopenworld.com>.
I should probably let Stefan answer this, but...
C. Michael Pilato wrote:
>> On 07.07.2014 17:07, C. Michael Pilato wrote:
>>> On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
>>>> My technical opinion that FSFS7/log addressing is slower by design,
>>>> because it's doing more (read index, then read data instead of just
>>>> read data) and only caching makes them comparable on performance to
>>>> FSFS6 repositories.
Ivan, it sounds like you've missed the important part of the design. It's designed to do LESS work in total, not more, because the cost of using the index is outweighed by the savings that it enables. As I understand it, a large saving is gained by re-ordering the data on disk during packing; that's why packing is essentially a requirement.
>>> I'm coming into this kinda late and after two weeks of vacation, so
>>> please forgive me if I misunderstand the above, but is it true that
>>> FSFS7 requires some kind of non-trivial caching just to match FSFS6's
>>> performance?
>>
>> Yup.
>
> May I then presume that for folks who have many repositories being
> hosted from a single server, FSFS7 will necessarily bring either a CPU
> performance hit (insufficient cache) or a RAM requirement/consumption
> hit (sufficient, ginormous cache)? Or is the cache configuration
> perhaps per-server rather than per-repository?
C-Mike, my understanding is that F7 comprehensively beats F6 speed, by large factors around x1.5 and more, in the kind of scenarios it's designed for. Caching is an assumed part of the design. I don't know how much it needs for what scenarios, or what you mean by 'non-trivial' or 'ginormous', but probably not as much as you might be led to think. I suggest you first look at Stefan's recent-ish test results [1] and other recent threads.
The only concerns about speed are about scenarios where it doesn't match F6 speed. While many scenarios are faster, some are slower, especially with the currently-default small cache size. Ivan reported some such scenarios [2].
My general observation is that wider testing is needed to draw firm conclusions.
- Julian
[1] "Re: Current FSFS performance [RAW]" <http://svn.haxx.se/dev/archive-2014-07/0004.shtml>
[2] "Subversion 1.9.0-dev FSFS performance tests" <http://svn.haxx.se/dev/archive-2014-06/0065.shtml>
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Mon, Jul 7, 2014 at 8:59 PM, Branko Čibej <br...@wandisco.com> wrote:
> On 07.07.2014 20:44, Stefan Fuhrmann wrote:
>> ... it makes SVN parse the
>> whole 64k block that the OS provides anyway ...
>
> [off-topic]
>
> See, this is the kind of statement that makes me uneasy. You make an
> assertion about "the OS" (or about "the CPU" or "the architecture") as
> if it were generally true for any OS, or CPU, or architecture; even when
> it's clear that this is simply not the case. And your implementation
> typically presupposes these generalizations.
Well, the feature is opt-in to begin with and the block size can be
configured per repository. So, there is nothing that relies 64kB being
a magic number with the guts of the OS. Having fewer fopen() and
read() operations should also always be more efficient.
Things become particularly efficient, however, if requesting larger blocks
is actually not an overhead at all - and that is the case with many device
drivers, RAID controller or OS read-ahead settings etc. (64..256kB).
It is just a little bit of extra benefit, I'd like to tap (it's also why we use
aligned reads now where feasible) but it's in no way a precondition for
the "block-read" feature to be efficient.
-- Stefan^2.
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Branko Čibej <br...@wandisco.com>.
On 07.07.2014 20:44, Stefan Fuhrmann wrote:
> ... it makes SVN parse the
> whole 64k block that the OS provides anyway ...
[off-topic]
See, this is the kind of statement that makes me uneasy. You make an
assertion about "the OS" (or about "the CPU" or "the architecture") as
if it were generally true for any OS, or CPU, or architecture; even when
it's clear that this is simply not the case. And your implementation
typically presupposes these generalizations.
I'm not saying that your optimizations have not been proven in general;
but we really shouldn't design our code based on assumptions about the
hardware or "the OS", and certainly shouldn't use them as arguments in
this particular discussion.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane@wandisco.com
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Jul 7, 2014 at 2:44 PM, Stefan Fuhrmann <
stefan.fuhrmann@wandisco.com> wrote:
> I just started the Windows tests in a "realistic" environment
> with a 4GB RAM server managing > 50GB of repository data.
> The goal is clearly that the default config is not slower than
> before and the computational overhead is roughly the same
> as we added when introducing manifest files for packed repos.
>
I have never considered the size of the repository in bytes that relevant
to performance, and other than the case of full text caches, I do not see
how it could matter.
For me, a realistic environment uses the Apache server and probably has at
least a few hundred repositories all of which are being used. For our
larger users it would be thousands of active repositories. Some of them
might be tens or hundreds of GB, but many of them are likely just a few
hundred MB.
I do not know what goes in the cache, but my assumption is that this sort
of environment would not lend itself well to caching of any kind. We
currently use whatever is the default.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Mon, Jul 7, 2014 at 5:54 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 07/07/2014 11:23 AM, Branko Čibej wrote:
>> On 07.07.2014 17:07, C. Michael Pilato wrote:
>>> On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
>>>> My technical opinion that FSFS7/log addressing is slower by design,
>>>> because it's doing more (read index, then read data instead of just
>>>> read data) and only caching makes them comparable on performance to
>>>> FSFS6 repositories.
>>> I'm coming into this kinda late and after two weeks of vacation, so
>>> please forgive me if I misunderstand the above, but is it true that
>>> FSFS7 requires some kind of non-trivial caching just to match FSFS6's
>>> performance?
>>
>> Yup.
Nope.
F7 is all about I/O reduction. No I/O, no reduction. The savings
are significant and a factor of 2 is typical. Even SSDs see speedups.
Data size and read operations (when to read what noderev / rep / ..)
are roughly unchanged. Thus, if caches are hot, the extra addressing
overhead cost you something between 0 (hot SVN caches) and
10% CPU (hot OS caches only).
F7 adds another feature that had to be made opt-in: "block-read".
Instead of reading only a few 100 bytes, it makes SVN parse the
whole 64k block that the OS provides anyway and puts the data
into cache. In environments with slow fopen(), that should save
CPU, but it requires significant SVN caches to be able to eventually
use the prefetched data. I'm particularly keen to see how much
of an impact that makes on Windows.
> May I then presume that for folks who have many repositories being
> hosted from a single server, FSFS7 will necessarily bring either a CPU
> performance hit (insufficient cache) or a RAM requirement/consumption
> hit (sufficient, ginormous cache)? Or is the cache configuration
> perhaps per-server rather than per-repository?
I just started the Windows tests in a "realistic" environment
with a 4GB RAM server managing > 50GB of repository data.
The goal is clearly that the default config is not slower than
before and the computational overhead is roughly the same
as we added when introducing manifest files for packed repos.
The problem with all that measurement is that it is very hard
to create an environment that behaves roughly as the real
world would (multiple repositories being created over a long
period of time, interleaving each other). It took me a whole
day to rewrite the copy script that creates meaningful data
sets for systems whose operation cannot be controlled (SAN).
-- Stefan^2.
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/07/2014 11:23 AM, Branko Čibej wrote:
> On 07.07.2014 17:07, C. Michael Pilato wrote:
>> On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
>>> My technical opinion that FSFS7/log addressing is slower by design,
>>> because it's doing more (read index, then read data instead of just
>>> read data) and only caching makes them comparable on performance to
>>> FSFS6 repositories.
>> I'm coming into this kinda late and after two weeks of vacation, so
>> please forgive me if I misunderstand the above, but is it true that
>> FSFS7 requires some kind of non-trivial caching just to match FSFS6's
>> performance?
>
> Yup.
May I then presume that for folks who have many repositories being
hosted from a single server, FSFS7 will necessarily bring either a CPU
performance hit (insufficient cache) or a RAM requirement/consumption
hit (sufficient, ginormous cache)? Or is the cache configuration
perhaps per-server rather than per-repository?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Tue, Jul 15, 2014 at 11:16 PM, Neels Hofmeyr <ne...@elego.de> wrote:
> On Mon, Jul 07, 2014 at 05:23:14PM +0200, Branko Čibej wrote:
>> On 07.07.2014 17:07, C. Michael Pilato wrote:
>> > On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
>> >> My technical opinion that FSFS7/log addressing is slower by design,
>> >> because it's doing more (read index, then read data instead of just
>> >> read data) and only caching makes them comparable on performance to
>> >> FSFS6 repositories.
>> > I'm coming into this kinda late and after two weeks of vacation, so
>> > please forgive me if I misunderstand the above, but is it true that
>> > FSFS7 requires some kind of non-trivial caching just to match FSFS6's
>> > performance?
>>
>> Yup.
>
> <from the off>
> Sounds bad, but then again I remember that wc-ng's projected performance
> boost over 1.6 has not been evident from the start, either.
> "It's what you make of it" ??
Well, given that the detailed results for Windows are in now
as well, the key bits are
* from hot SVN caches, there is no difference between f6 and f7
* from hot OS caches, it's a mixed bag and depends on various factors
* reading from disk, f7 is faster for packed repos even with default configs
* "block-read" doubles the relative speedup but requires larger caches
-- Stefan^2.
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Neels Hofmeyr <ne...@elego.de>.
On Mon, Jul 07, 2014 at 05:23:14PM +0200, Branko Čibej wrote:
> On 07.07.2014 17:07, C. Michael Pilato wrote:
> > On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
> >> My technical opinion that FSFS7/log addressing is slower by design,
> >> because it's doing more (read index, then read data instead of just
> >> read data) and only caching makes them comparable on performance to
> >> FSFS6 repositories.
> > I'm coming into this kinda late and after two weeks of vacation, so
> > please forgive me if I misunderstand the above, but is it true that
> > FSFS7 requires some kind of non-trivial caching just to match FSFS6's
> > performance?
>
> Yup.
<from the off>
Sounds bad, but then again I remember that wc-ng's projected performance
boost over 1.6 has not been evident from the start, either.
"It's what you make of it" ??
~Neels
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Branko Čibej <br...@wandisco.com>.
On 07.07.2014 17:07, C. Michael Pilato wrote:
> On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
>> My technical opinion that FSFS7/log addressing is slower by design,
>> because it's doing more (read index, then read data instead of just
>> read data) and only caching makes them comparable on performance to
>> FSFS6 repositories.
> I'm coming into this kinda late and after two weeks of vacation, so
> please forgive me if I misunderstand the above, but is it true that
> FSFS7 requires some kind of non-trivial caching just to match FSFS6's
> performance?
Yup.
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
> My technical opinion that FSFS7/log addressing is slower by design,
> because it's doing more (read index, then read data instead of just
> read data) and only caching makes them comparable on performance to
> FSFS6 repositories.
I'm coming into this kinda late and after two weeks of vacation, so
please forgive me if I misunderstand the above, but is it true that
FSFS7 requires some kind of non-trivial caching just to match FSFS6's
performance?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 1 July 2014 03:27, Johan Corveleyn <jc...@gmail.com> wrote:
> On Mon, Jun 30, 2014 at 6:21 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On 30 June 2014 18:51, Stefan Fuhrmann <st...@wandisco.com> wrote:
>>> On Mon, Jun 30, 2014 at 4:06 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>>
>>>> On 19 June 2014 14:21, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>> > Hi,
>>>> >
>>>> > I've performed several FSFS performace tests using latest Subversion
>>>> > from trunk@r1602928.
>>>> >
>>>> I've re-ran my FSFS performance tests with trunk@r1605444 using latest
>>>> fsfs7 performance fixes including combining indexes to revision files.
>>>
>>>
>> [..]
>>
>>> Also, it seems that some of these tests are run from hot
>>> caches - causing a lot of variation and making comparison
>>> pointless. An extreme case:
>>>
>>> ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
>>> Copyright(C) 2002, Jem Berkes <jb...@pc-tools.net>
>>>
>>> === "svn log http://localhost/svn/ruby-fsfs6-unpacked >nul" ===
>>>
>>> Execution time: 216.064 s
>>> ...
>>> Execution time: 13.268 s
>>> ...
>>> Execution time: 18.061 s
>>>
>> Yes, I use hot caches and already noted this in my report: "Every test
>> was run 3 times and only two latest used"
>>
>> I don't see the reason to test on cold disk caches because I assume
>> that caches in the real servers are somewhat hot. No matter how it's
>> complex to compare the results on hot disk caches. For me, log
>> addressing feature is definitely useless if it slower on hot disk
>> caches.
>
> Innocent bystander's opinion: I appreciate your critical look at the
> performance of fsfs7, Ivan, but I disagree. I think in lots of
> real-world cases cold cache performance is much more important than
> hot cache performance.
>
> Especially in a big / busy repository and for use cases such as "svn
> log". I usually don't ask the same "svn log" three times in a row.
> User A might request "svn log" of some file or subtree, user B then
> asks for another subtree, and so on.
Caches on real-world server that I monitor are somewhat warm/hot for
busy repositories. The disk metadata be already cached, at least. But
I agree that querying "svn log" three times in a row for the same path
is too optimistic.
However, note that sequential updates for the same path is quite usual
for busy repositories.
> It's the performance of that first (and usually only) request that matters most to me.
>
I think we should care about the overall performance. On the other
hand, performance optimization should be targeted to the real
cases where users experience performance bootlenecks.
> Same for export: different users export different parts of the
> repository all the time. Not the same part a couple of times in a row
> (except perhaps right after some release / milestone / ...).
>
> So I for one am more interested in cold-cache performance
> improvements, even if they come at a (hopefully small) hot-cache
> performance cost.
>
> OTOH, I do wonder about these (hot-cache) performance regressions ...
> maybe they can still be improved?
>
My technical opinion that FSFS7/log addressing is slower by design,
because it's doing more (read index, then read data instead of just
read data) and only caching makes them comparable on performance to
FSFS6 repositories.
--
Ivan Zhakov
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Jun 30, 2014 at 6:21 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 30 June 2014 18:51, Stefan Fuhrmann <st...@wandisco.com> wrote:
>> On Mon, Jun 30, 2014 at 4:06 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>
>>> On 19 June 2014 14:21, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>> > Hi,
>>> >
>>> > I've performed several FSFS performace tests using latest Subversion
>>> > from trunk@r1602928.
>>> >
>>> I've re-ran my FSFS performance tests with trunk@r1605444 using latest
>>> fsfs7 performance fixes including combining indexes to revision files.
>>
>>
> [..]
>
>> Also, it seems that some of these tests are run from hot
>> caches - causing a lot of variation and making comparison
>> pointless. An extreme case:
>>
>> ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
>> Copyright(C) 2002, Jem Berkes <jb...@pc-tools.net>
>>
>> === "svn log http://localhost/svn/ruby-fsfs6-unpacked >nul" ===
>>
>> Execution time: 216.064 s
>> ...
>> Execution time: 13.268 s
>> ...
>> Execution time: 18.061 s
>>
> Yes, I use hot caches and already noted this in my report: "Every test
> was run 3 times and only two latest used"
>
> I don't see the reason to test on cold disk caches because I assume
> that caches in the real servers are somewhat hot. No matter how it's
> complex to compare the results on hot disk caches. For me, log
> addressing feature is definitely useless if it slower on hot disk
> caches.
Innocent bystander's opinion: I appreciate your critical look at the
performance of fsfs7, Ivan, but I disagree. I think in lots of
real-world cases cold cache performance is much more important than
hot cache performance.
Especially in a big / busy repository and for use cases such as "svn
log". I usually don't ask the same "svn log" three times in a row.
User A might request "svn log" of some file or subtree, user B then
asks for another subtree, and so on. It's the performance of that
first (and usually only) request that matters most to me.
Same for export: different users export different parts of the
repository all the time. Not the same part a couple of times in a row
(except perhaps right after some release / milestone / ...).
So I for one am more interested in cold-cache performance
improvements, even if they come at a (hopefully small) hot-cache
performance cost.
OTOH, I do wonder about these (hot-cache) performance regressions ...
maybe they can still be improved?
--
Johan
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 30 June 2014 18:51, Stefan Fuhrmann <st...@wandisco.com> wrote:
> On Mon, Jun 30, 2014 at 4:06 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>> On 19 June 2014 14:21, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> > Hi,
>> >
>> > I've performed several FSFS performace tests using latest Subversion
>> > from trunk@r1602928.
>> >
>> I've re-ran my FSFS performance tests with trunk@r1605444 using latest
>> fsfs7 performance fixes including combining indexes to revision files.
>
>
[..]
> Also, it seems that some of these tests are run from hot
> caches - causing a lot of variation and making comparison
> pointless. An extreme case:
>
> ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
> Copyright(C) 2002, Jem Berkes <jb...@pc-tools.net>
>
> === "svn log http://localhost/svn/ruby-fsfs6-unpacked >nul" ===
>
> Execution time: 216.064 s
> ...
> Execution time: 13.268 s
> ...
> Execution time: 18.061 s
>
Yes, I use hot caches and already noted this in my report: "Every test
was run 3 times and only two latest used"
I don't see the reason to test on cold disk caches because I assume
that caches in the real servers are somewhat hot. No matter how it's
complex to compare the results on hot disk caches. For me, log
addressing feature is definitely useless if it slower on hot disk
caches.
--
Ivan Zhakov
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Mon, Jun 30, 2014 at 4:06 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 19 June 2014 14:21, Ivan Zhakov <iv...@visualsvn.com> wrote:
> > Hi,
> >
> > I've performed several FSFS performace tests using latest Subversion
> > from trunk@r1602928.
> >
> I've re-ran my FSFS performance tests with trunk@r1605444 using latest
> fsfs7 performance fixes including combining indexes to revision files.
>
Makes sense, that's close enough to what I used
as a basis last week. Optimizations since then have
mostly brought down the CPU overhead when reading
from SSD, RAM disk or disk cache.
> This time I used the same Windows VM hosted on Macbook with SSD disk.
>
Haven't looked at the results there, yet.
> Also I run the same tests on Windows VM on typical IBM x3620 M3 server
> with SAS raid attached spinning disks on Windows Hyper-V: this is very
> typical configuration in SMB environment.
>
Yes, that is certainly a typical configuration.
> Please find results in attached pdf for easier reading. I leave making
> conclusions to readers.
>
Could you re-run the dump tests with -r0:5000 as you did
two weeks ago. Otherwise, it will be hard to check the
results for plausibility (I don't have access to my server
hardware for the next 3 months or so).
Also, it seems that some of these tests are run from hot
caches - causing a lot of variation and making comparison
pointless. An extreme case:
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes <jb...@pc-tools.net>
=== "svn log http://localhost/svn/ruby-fsfs6-unpacked >nul" ===
Execution time: 216.064 s
...
Execution time: 13.268 s
...
Execution time: 18.061 s
I'm not pretending that my performance tests are scientific, but my
> goal is just to validate that fsfs7 is not worse than fsfs6.
>
That's a good goal. I'm currently through with my FSFS
TODO, except for documentation and committing a change
you suggested in Berlin. I'll then write a post on the pitfalls
of repo performance testing (plus a script to avoid them).
Furthermore, I'll convert the raw measurement data (plus
additional tests run later) into something easier to consume.
-- Stefan^2.
Re: Subversion 1.9.0-dev FSFS performance tests
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 19 June 2014 14:21, Ivan Zhakov <iv...@visualsvn.com> wrote:
> Hi,
>
> I've performed several FSFS performace tests using latest Subversion
> from trunk@r1602928.
>
I've re-ran my FSFS performance tests with trunk@r1605444 using latest
fsfs7 performance fixes including combining indexes to revision files.
This time I used the same Windows VM hosted on Macbook with SSD disk.
Also I run the same tests on Windows VM on typical IBM x3620 M3 server
with SAS raid attached spinning disks on Windows Hyper-V: this is very
typical configuration in SMB environment.
Please find results in attached pdf for easier reading. I leave making
conclusions to readers.
I'm not pretending that my performance tests are scientific, but my
goal is just to validate that fsfs7 is not worse than fsfs6.
--
Ivan Zhakov