On Tue, Mar 8, 2011 at 17:01, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Mar 08, 2011 at 01:46:23PM +0000, Philip Martin wrote:
>> stefan2_at_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
Received on 2011-03-08 15:08:53 CET