Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of
 Terry.Dooher@naturalmotion.com designates 86.12.140.205 as permitted sender)
From: Terry Dooher <Terry.Dooher@naturalmotion.com>
To: Ben Reser <ben@reser.org>, "users@subversion.apache.org"
	<users@subversion.apache.org>
Date: Thu, 15 May 2014 09:15:56 +0100
Subject: RE: SVNCacheRevProps and other performance tweaks.
Thread-Topic: SVNCacheRevProps and other performance tweaks.
Thread-Index: Ac9vp5K/1SKPtTtzSxeY9hnVGK4k9AAbihaA
Message-ID: <1CE1BECC0915A6448EAE5D7080EDA905076A28B7B4@oxexc1>
References: <1CE1BECC0915A6448EAE5D7080EDA905076A28B766@oxexc1>
 <5373BED2.5040200@reser.org>
In-Reply-To: <5373BED2.5040200@reser.org>
Accept-Language: en-US, en-GB
Content-Language: en-US
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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 infrastructur=
e
> and directly as mod_authz_svn.  This has significantly less overhead, whi=
le
> 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 compon=
ents
and filenames within restricted areas during log operations?

>> SVNCacheRevProps - Currently 'Off'. is it only of benefit in specific sc=
enarios?
> 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 slow=
er
> 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 processe=
s;
I see now that setting it to 256MB per process might incur a slight overhea=
d :)
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.