On Sun, Jan 6, 2013 at 3:10 PM, Daniel Shahaf <danie...@elego.de> wrote:
> Branko Čibej wrote on Sun, Jan 06, 2013 at 11:27:09 +0100: > > On 06.01.2013 10:43, Bert Huijben wrote: > > > The revprop and revision cache are in fsfs, not the repos layer... > > > > > > In what way are you then comparing the backends? > > > > > > You are now comparing a backend+caching to a backend without caching. > I used "backend" as a term for FS API implementation. > > I’m not against dropping support, but if we do it we should do it for > > > the right reasons, not by using skewed numbers. > As others already pointed out, I don't think those numbers are skewed. They answer a simple question: What are the size & performance differences between both implementations in a typical setup? IOW, what a user would gain when switching from BDB to FSFS considering that such a conversion is not for free. The claim here is not that BDB itself was rubbish but that our current use of it results in a much worse user experience than FSFS. > Caching is part of the FSFS backend. One would assume that a key-value > > database like BDB would have its own cache, which is therefore > > implicitly part of the BDB back-end. I don't see how you could construe > > these numbers as skewed. > > Just look at all the different svn_cache__t instances in FSFS. They > include, for example, a cache of combined svndiff windows --- that's not > something the db layer is going to have. > While that is true, there plenty of algorithmic improvements have been made to the FSFS code as well. I just re-ran one of the benchmarks with a completely default svnserve configuration (16M cache, no fulltext, txdelta nor revprop caching). Results: (1): (2) : (3) 1 : 6.8 : 5.0 svn-bench null-log ^/trunk -v -g 1 : 15 : 5.8 (second run) The missing delta and revprop caches hurt the space-optimized FSFS configuration (3) much more than FSFS defaults. -- Stefan^2. -- Certified & Supported Apache Subversion Downloads: * http://www.wandisco.com/subversion/download *
