Deferring FSFS revprop caching to 1.10

Hi all,

I ran a few tests to determine the impact of the missing
revprop caching on trunk. For checkouts, the overhead
is ~2 extra CPU cores per saturated 10Gb network. Even
that will be not be severe issue to users and the changes
mentioned below bring it down to .5 cores.

'svn log -v' is a factor of 2 slower for the http: client and
4x for the svn: client. Server load is approx 3x and 8x
as high, respectively, if revprop caching is not available.

Most of the overhead is spent parsing packed revprop
manifest info. I wrote a series of patches that reduces
the overhead such that the http: client will see no real
difference while the svn: client takes only 50% longer
than it would with a revprop caching server.

These are only ballpark numbers run on a system with
high bandwidths, low latencies and low fopen() overhead.
However, I think we can tune the revprop file granularity
and parsing now and defer the FSFS revprop caching to
1.10 without a massive impact on users.

-- Stefan^2.
Received on 2014-10-23 14:53:14 CEST