subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fuhrmann <stefan.fuhrm...@wandisco.com>
Subject Re: Deferring FSFS revprop caching to 1.10
Date Tue, 04 Nov 2014 01:03:33 GMT
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.

Mime
View raw message