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

Re: Comparison testing: { FSFS, BDB } x { 1.5.4, trunk }

From: David Glasser <glasser_at_davidglasser.net>
Date: Wed, 29 Oct 2008 15:15:22 -0700

On Sat, Oct 25, 2008 at 11:45 PM, David Glasser
<glasser_at_davidglasser.net> wrote:
> On Sat, Oct 25, 2008 at 3:10 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> I did a little bit of simple comparison testing between FSFS and BDB in
>> 1.5.4 and trunk. My testing involved loading a dumpfile of 5000 revisions
>> (taken from our own repository), then doing some single-revision dumps at a
>> few time-slices across the loaded repository.
>>
>> Here are the highlights (percentages are ballpark estimates).
>>
>> In trunk, FSFS:
>>
>> is significantly slower (30%) for writes operations. I have no idea why.
>
> As discussed in the other thread, the obvious thing to assume would be
> that all the reads and rights of the rep cache DB are slowing you
> down... try disabling that (just take out all the calls into
> rep-cache.h from fs-fs.c) and try again?

Have you had a chance to try this? I can give you the appropriate
patch if you'd like.

--dave

>> is a bit faster for reads (20%).
>>
>> showed no meaningful disk usage changes. But I'm pretty sure this is
>> an artifact of the testing dataset, which isn't as up-to-date-branch-heavy
>> as more recent revision ranges in our source tree are.
>>
>> In trunk, Berkeley DB:
>>
>> is significantly faster (50%) for write operations. This is almost
>> certainly because post-commit deltification is doing a single
>> deltification instead of touching a chain of files.
>>
>> is significantly slower (300%) for read operations. Distance to
>> nearest fulltext?
>>
>> showed significant improvement in disk usage (20% savings) in trunk.
>> For the same reasons that FSFS didn't show much improvement here, I
>> must assume rep-sharing wasn't the real win here. More likely the
>> minimization of fulltexts (one per line of history) is the win here.
>>
>> In all things except disk usage (now in trunk), FSFS remains a clear winner
>> over BDB in this testing.
>>
>> Attached are the script I used and a spreadsheet with the actual findings.
>>
>> --
>> C. Michael Pilato <cmpilato_at_collab.net>
>> CollabNet <> www.collab.net <> Distributed Development On Demand
>>
>> #!/bin/sh
>>
>> for svnadmin in \
>> /home/cmpilato/projects/subversion/subversion/svnadmin/svnadmin \
>> /home/cmpilato/projects/subversion-1.5.x/subversion/svnadmin/svnadmin ; do
>> for fstype in fsfs bdb; do
>> echo "### ${svnadmin} ${fstype}"
>> for i in 1 2 3; do
>> rm -rf repos
>> ${svnadmin} create --fs-type ${fstype} repos
>> echo "--- Dumpfile load"
>> time -p ${svnadmin} load -q repos < dumpfile
>> done
>> echo "### --- Repository size"
>> du -sk repos
>> for rev in 10 2500 5000; do
>> for i in 1 2 3; do
>> echo "--- Revision dump (r${rev})"
>> time -p ${svnadmin} dump -q repos -r ${rev} > /dev/null
>> done
>> done
>> done
>> done
>>
>>
>
>
>
> --
> David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
>

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-29 23:15:40 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.