On Thu, Oct 23, 2014 at 2:51 PM, Stefan Fuhrmann <
stefan.fuhrmann_at_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.
Received on 2014-11-04 02:06:17 CET