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

mod_authz_svn and caching

From: Hans van Kranenburg <hans.van.kranenburg_at_mendix.com>
Date: Sat, 5 Nov 2016 00:19:54 +0100

(please keep me in Cc: since I'm not on the list (yet))


We recently switched from using a htgroup file with apache2 to using the
<repo>/conf/authz file with AuthzSVNReposRelativeAccessFile, for
performance reasons.

The authz files are really simple, like this:

foo_at_example.com = rw
bar_at_example.com = rw

The performance benefit is ludicrous, but we ran into an issue:

Since we have nginx in front of the apache2+svn box, there's only a
small amount of connections that is opened between nginx and apache2.
Those connections carry requests from different end users, and live
relatively long.

Inside mode_authz_svn the per-repo authz files are cached using a
per-connection cache.

Since we dynamically create and remove repositories, and dynamically add
and remove users, users that are added to a repository are not able to
use the repository immediately. Also, our automated create repo flow
which first creates the repo, checks if it can be accessed correctly and
then adds the user to the authorization list triggers this problem in
nearly 100% of the cases.

Currently, I'm running a modified mod_authz_svn that simply disables
caching (not causing any noticable performance difference):


I understand that it's possible to create really complex authorization
structures inside a file for a single repository, so the caching of the
result of parsing the file might be useful in some cases.

My suggestion about improving this situation would be to simply save the
modification time of the authz file with the cached information, and
check the mtime again on every request, invalidating the cache whenever
we notice that the file has changed.

I can give it a shot to prepare a patch to do this, if wanted.

Have fun,

Hans van Kranenburg
Received on 2016-11-05 06:24:58 CET

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

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