On Thu, Oct 23, 2014 at 2:51 PM, Stefan Fuhrmann < stefan.fuhrm...@wandisco.com> wrote:
> 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. > Since r1634880, the principal improvements to revprop parsing are in /trunk. I do have additional patches that are good for another 25..30% server-side improvement but they are not trivial and will not be visible on the client side (unless the server is under heavy load). Therefore, I won't commit those patches. IOW, revprop handling on /trunk is now complete for 1.9. -- Stefan^2.
