[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: SVNCacheRevProps and other performance tweaks.

From: Terry Dooher <Terry.Dooher_at_naturalmotion.com>
Date: Thu, 15 May 2014 09:15:56 +0100

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:
> http://subversion.apache.org/docs/release-notes/1.8.html#revprop-caching
> http://subversion.apache.org/docs/release-notes/1.8.html#revprop-packing

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.

Terry.
Received on 2014-05-17 01:31:40 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.