[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Deferring FSFS revprop caching to 1.10

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Tue, 4 Nov 2014 02:03:33 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.