subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terry Dooher <>
Subject RE: SVNCacheRevProps and other performance tweaks.
Date Thu, 15 May 2014 08:15:56 GMT
From: Ben Reser Sent: 14 May 2014 20:07
> On 5/14/14, 10:11 AM, Terry Dooher wrote:
>> SVNPathAuthz -  Would short_circuit save me any processing time in this
>> scenario or is it only useful for people with LDAP or other auth systems that
>> might slow down request processing?
> short_circuit: The secondary path checks do not generate sub-requests but
> rather short circuit the httpd authentication/authorization infrastructure
> and directly as mod_authz_svn.  This has significantly less overhead, while
> being as secure as on provided that the only authorization module that is
> path aware is mod_authz_svn.  If you're using authz unless you have an
> extremely rare case you want this setting.
> In your scenario you want to use short_circuit.

That's so much clearer now and sounds like something I can definitely use.
As I understand it, the downside is that the server will reveal path components
and filenames within restricted areas during log operations?

>> SVNCacheRevProps - Currently 'Off'. is it only of benefit in specific scenarios?
> Actually I think it's more that you really must have this enabled if you have
> revprop packing turned on.  I can't think of a reason you don't want this
> turn off other than desiring to reduce resource usage at the cost of slower
> performance.
> The documentation in question is the release notes:

Makes sense. The dump/load cycle I've just finished was to bring in the
revprop packing changes, but I didn't appreciate the need for caching to
reduce CPU load.

>> SVNInMemoryCacheSize
> With the worker or event MPMs you are able to share the cache between the
> threads within the same processes.  This allows you to set a larger cache
> size since you'll have fewer processes and more of the threads will gain
> access to the cache, making it to be more effective.

Ah, of course. I missed the k in the default value and figured that a
16-fold increase would be a small, suitable value for ~100 prefork processes;
I see now that setting it to 256MB per process might incur a slight overhead :)
I can run the PHP under lighttpd, easily, so moving to the worker mpm is
the best option.

Thanks for such a comprehensive response.


View raw message