On Tue, Mar 8, 2011 at 17:01, Stefan Sperling <s...@elego.de> wrote: > On Tue, Mar 08, 2011 at 01:46:23PM +0000, Philip Martin wrote: >> stef...@apache.org writes: >> >> > Author: stefan2 >> > Date: Mon Mar 7 22:57:04 2011 >> > New Revision: 1079008 >> > >> > URL: http://svn.apache.org/viewvc?rev=1079008&view=rev >> > Log: >> > Set FSFS cache default size to 16 MB. This is the same default as >> > for everybody else, namely the server processes. Thus, it should >> > be reasonable value on the same machines. >> >> 16MB may be "reasonable" for normal usage but it still has a significant >> effect on the testsuite. The testsuite is an unusual access pattern, it >> runs thousands of commands on small repositories. Using a 1MB cache I >> can run the testsuite for ra_local/FSFS in 10m15s, with 16MB cache that >> increases to 12m30s, a 20% increase. There is a similar increase when >> testing ra_svn/FSFS using the default Linux svnserve (a threaded >> svnserve has a shared cache so isn't affected). >> >> svnserve and svnadmin both have a -M option, was there any discussion >> about using a single letter option for this feature? This could be used >> by the testuite to restrict the cache size, but for ra_local/FSFS >> testing there is no way to restrict the svn client. > > Shouldn't the cache be off by default? > > We have precedence for other features like this that are strictly opt-in, > e.g. memcached support in FSFS. I don't think we should assume that the > new cache code is perfect and enable it by default on any repository for > any 1.7 server. The feature has not had any exposure in the real world yet. > > So I think it would be better if the cache was off by default, and must be > enabled in a configuration file. I suppose svnserve and mod_dav_svn > configuration files would be the best location for this, because the > purpose of the cache seems to be to speed up server operation. > An 'svn' process has a short lifetime so the benefit of this cache > seems dubious in that situation. I don't see any reason to even provide > a way to turn it on there. > +1!
-- Ivan Zhakov
