Deferring FSFS revprop caching to 1.10

[Stefan Fuhrmann <st...@wandisco.com>]

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.

Re: Deferring FSFS revprop caching to 1.10

[Stefan Fuhrmann <st...@wandisco.com>]

On Thu, Oct 23, 2014 at 2:51 PM, Stefan Fuhrmann <
stefan.fuhrmann@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.