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

Re: FSFS format7 status and first results

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Thu, 21 Feb 2013 12:45:43 +0100

On Thu, Feb 21, 2013 at 12:06 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:

> On Thu, Feb 21, 2013 at 11:05 AM, Stefan Fuhrmann
> <stefan.fuhrmann_at_wandisco.com> wrote:
> > On Mon, Feb 18, 2013 at 5:54 PM, Mark Phippard <markphip_at_gmail.com>
> wrote:
> >> On Sat, Feb 16, 2013 at 4:30 PM, Stefan Fuhrmann
> >> <stefan.fuhrmann_at_wandisco.com> wrote:
> ...
> >> > Quite a number of reasons:
> >> >
> >> > * easy setup
> >> > * minimal overhead (I want to get as close to measuring pure
> >> > FS layer performance as possible)
> >> > * easy to debug and profile
> >>
> >> I get that for development purposes, but I would personally like to
> >> see that the caching etc. is yielding benefits when HTTP is used.
> >
> >
> > Apache should only add constant overhead, i.e. the
> > absolute savings should be roughly the same. Once
> > the cache-server branch is finished, the difference
> > in cache efficiency & effect between svnserve and
> > Apache should be gone.
>
> I guess the question is mainly: how much of the caching benefit will
> be visible to the end-user with mod_dav_svn? Or will it perhaps be
> "hidden" by overhead of HTTPv2 etc ...?
>

Format7 is not so much about caching than real I/O
reduction. It only requires (better) caching to get the
maximum benefit from the new heuristics.

And yes, Apache will come with some extra overhead
when compared to svnserve. In the BDB vs. FSFS
comparison, even adding Apache and working copy
overhead could not mask the fundamental performance
differences between both implementations. Format7
vs. format6 will show an even larger difference on
the lowest level. So, the client *will* see improvements.

> In the first place in a fast LAN (that might be something you can test
> relatively easily), but secondary also in a WAN ... how much
> performance improvement remains when executing particular operations
> ...
>

One operation that will become dramatically faster
is svn log and hopefully svn log -g (and other merge-
related queries). Today, some setups get < 10 revs/s
for a 'svn log -v ^/' simply due to serial disk I/O. Those
setups can be boosted to 100k revs/s. With cold caches.

-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Received on 2013-02-21 12:46:19 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.