Branko Čibej <brane_at_wandisco.com> writes:
>> From the performance point of view there will be no big benefits to enable
>> log addressing for an existing repository, because the existing old part
>> of the repository will remain to be addressed physically.
>
> I disagree with your assessment. Certainly, as long as there are "live"
> delta chains in the repository that reach all the way into
> physically-indexed content, there will less performance benefit from
> logical addressing than in a "pure" FSFSv7. But this state will not
> persist "forever", certainly not for actively changed content.
I did a small attempt in measuring the performance benefits of the mixed-mode
addressing. Please note that these results are only provided for the Windows
platform and only cover basic operations over two protocols. My tests were
done under Windows 8.1 Professional (Apache HTTP Server 2.2.29, serf 1.3.8),
a part of the batch file covering the 'file://' protocol is attached.
I used the http://tortoisesvn.googlecode.com/svn/ repository (25851 revisions)
in my experiments. What I did was building 1.9.0 binaries from r1637183 and
r1637184. Right after that I started examining, what would have happened with
the performance in three different scenarios:
- The whole repository (25851 revisions) received an upgrade to FSFS7, and all
revisions are physically addressed, i.e. no mixed-mode addressing happened.
This is the default upgrade behavior as of r1637184.
- The repository received an upgrade to FSFS7 with mixed-mode addressing and
has been accumulating new logically addressed revisions for one year. A
corresponding revision span is the following:
(r24752, 9/10/2013 → r25851, 9/10/2014)
- The repository received an upgrade to FSFS7 with mixed-mode addressing and
has been accumulating new logically addressed revisions for three years. A
corresponding revision span is the following:
(r21959, 9/10/2011 → r25851, 9/10/2014)
In one year (r24752, 9/10/2013 → r25851, 9/10/2014), the performance boost
from using the mixed addressing mode would be the following:
(http://)
svn-bench null-log unpacked 15.765 → 15.682 s (0.5 % gain)
svn-bench null-log packed 16.811 → 16.400 s (2.4 % gain)
svn-bench null-log -v unpacked 16.236 → 16.130 s (0.7 % gain)
svn-bench null-log -v packed 17.166 → 16.921 s (1.4 % gain)
svn-bench null-export unpacked 43.808 → 43.644 s (0.4 % gain)
svn-bench null-export packed 43.010 → 43.039 s (0.1 % loss)
(file://)
svn-bench null-log unpacked 3.303 → 3.276 s (0.8 % gain)
svn-bench null-log packed 5.902 → 5.947 s (0.8 % gain)
svn-bench null-log -v unpacked 12.530 → 12.688 s (1.3 % loss)
svn-bench null-log -v packed 13.514 → 13.545 s (0.2 % gain)
svn-bench null-export unpacked 12.362 → 12.434 s (0.6 % gain)
svn-bench null-export packed 12.316 → 12.170 s (1.2 % gain)
In three years (r21959, 9/10/2011 → r25851, 9/10/2014), the performance boost
from using the mixed addressing mode would be the following:
(http://)
svn-bench null-log unpacked 15.765 → 15.313 s (2.9 % gain)
svn-bench null-log packed 16.811 → 16.193 s (3.7 % gain)
svn-bench null-log -v unpacked 16.236 → 15.596 s (3.9 % gain)
svn-bench null-log -v packed 17.166 → 16.648 s (3.0 % gain)
svn-bench null-export unpacked 43.808 → 43.930 s (0.3 % loss)
svn-bench null-export packed 43.010 → 43.169 s (0.4 % loss)
(file://)
svn-bench null-log unpacked 3.303 → 3.413 s (3.3 % loss)
svn-bench null-log packed 5.902 → 5.942 s (0.7 % loss)
svn-bench null-log -v unpacked 12.530 → 12.458 s (0.6 % gain)
svn-bench null-log -v packed 13.514 → 13.164 s (2.6 % gain)
svn-bench null-export unpacked 12.362 → 12.945 s (4.7 % loss)
svn-bench null-export packed 12.316 → 12.537 s (1.8 % loss)
I do not want to make any conclusions on this topic. However, my results do
not show any obvious advantage of having the mixed-mode addressing enabled for
the sample (http://tortoisesvn.googlecode.com/svn/) repository. Even after
*three* years of logically addressed revisions landing into the repository,
the performance gains still fluctuate around zero.
Regards,
Evgeny Kotkov
Received on 2014-11-11 20:42:08 CET