On 08.03.2011 14:46, 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).
The patch attached fixes the performance penalty
for "make check" by disabling membuffer caches
over ra_local by default. Since svn_ra_initialize is
being called early in main(), the setting can later
be overwritten by settings from e.g. a config file.
Could you verify that / whether this fixes your
performance issue?
> svnserve and svnadmin both have a -M option, was there any discussion
> about using a single letter option for this feature?
No.
> 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.
As already shown in a different thread, the memory
consumption should actually go down for any non-
trivial repository.
> Should we add the -M option to the svn client?
Due to its limited applicability (FSFS via file:/// only),
I'm kind of -0 on adding that to the client. It is clearly
useful in certain cases but it may be hard to make
that clear to the average user.
It seems more likely to be a "on server" feature: run
svn (or others) from hook scripts. For max. speed,
admins could tweak their svn config file accordingly.
> Should we make it configurable via .subversion/config instead or as well?
See above.
> If svnadmin gets configured by .subversion/config should we remove the
> command line option?
I'm +0 for the config file. For me, the CL is slightly
more convenient as it is easier to play with different
parameter values. The config file has the advantage
that each setting can be extensively documented /
commented.
-- Stefan^2.
Received on 2011-03-08 21:38:05 CET