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

Re: mod_authz_svn and caching

From: Stefan Fuhrmann <eqfox_at_web.de>
Date: Sat, 5 Nov 2016 11:44:56 +0100

Hi Hans,

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))
>
> Hi,
>
> 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):
>
> http://paste.debian.net/plainh/0b2f4e20
>
> 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".

-- Stefan^2.
Received on 2016-11-05 11:59:16 CET

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