Thanks for the issue report! There seem to be two independent
approaches that we could take to address the problem -- see below.
On 05.11.2016 00:19, Hans van Kranenburg wrote:
> (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.
Up to here, everything should "just" work.
> 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.
Yes, the dynamic aspect is an issue.
> 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.
Looking at your workaround, I think the cleanest solution would be to
introduce an AuthzSVNDisableCache option. Just grep in the same source
file for AuthzSVNNoAuthWhenAnonymousAllowed and no_auth_when_anon_ok as
an example for a boolean option. Use the new flag in get_access_conf()
to optionally skip the cache access.
> 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.
svnserve already has code for that. The idea is to use content SHA1
instead of timestamps. The latter might be racy / have to low a
resolution during the repo creation phase where an authz file could
be created first and then filled shortly thereafter.
SHA1, on the other hand, are immediately available for in-repository
authz and even for external files, calculating the SHA1 is ~10x as
fast as actually parsing the file.
The plan is to introduce a new authz implementation in, hopefully, 1.10
and making the cache invalidation available everywhere is part of that.
> I can give it a shot to prepare a patch to do this, if wanted.
Patches are always welcome. I think adding AuthzSVNDisableCache
should be easy enough for "giving it a shot".
Received on 2016-11-05 11:59:16 CET