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

Re: Subversion 1.9.0-dev FSFS performance tests

From: Branko Čibej <brane_at_wandisco.com>
Date: Sat, 21 Jun 2014 22:10:07 +0200

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 <stefan.fuhrmann_at_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_at_wandisco.com
Received on 2014-06-21 22:10:44 CEST

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

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