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.
