On 23 July 2014 17:19, Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> wrote: > Updated and final results: > > * svnadmin dump results now included, f6 / f7 is +/-20% > > * fixed anomaly with ra_serf, results consistent with previous findings > 'null-export' tests have been rerun and old results been replaced > > * added a page on how 'null-export' reacts on cache configuration > to get a better picture of how cache size, ra layer and block-read > interact when caches are hot. Data for small or cold caches has > already been in covered in other tests. > I just want to note that your conclusions don't point the fact that there is performance degradation in many case: 1. 'svn log -v' for bsd-nopack repository over svn:// in 'FAST' configuration is 51% slower 2. 'svn export' for ruby-nopack repository over file:// in 'FAST' configuration is 23% slower
So I ask for unbiased performance tests. As far as I remember, you advertised the 2x-10x performance improvement on the hackaton in Berlin (that is supposed to be already achieved at the time of presentation). Then we have found (and fixed) several cases of performance degradation. But you didn't tell us about these cases. So I consider your performance measurements as biased. I'm still getting bad numbers in my tests. But obviously, my tests can be considered as a biased too because I am strongly against this feature for many reasons. That's why we need an unbiased performance test. I think that the unbiased tester should pay attention to ensure both the following: 1) there is *significant* performance improvement for some realistic cases 2) there are no performance degradation in *all the typical Subversion usage configurations* (including the worst ones). It seems that CollabNET and other hosting providers possibly have one of the worst configuration for log-adressing feature. Multiple users access over HTTP to a number of gigabyte-sized repositories (so there are no enough memory for enormous caches). Authorization is enabled (my tests shows that this is important). Apache httpd uses prefork MPM (that should eliminate the caches). Also I'd like to note that your method to achieve 'Cold' state on Windows is totally wrong: you're basically allocating *all* available memory by 'ClearMemory' tool making OS starving on all resources [1]. It's abnormal situation for operating system. So your 'Cold' state results are irrelevant. [1] https://svn.apache.org/repos/asf/subversion/trunk/tools/dev/benchmarks/RepoPerf/ClearMemory.cpp -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
