Re: draft concept for acl caching

On Tuesday 28 January 2003 07.59, Robert Collins wrote:

> we should be able to save significant overhead in complex acl
> checking scenarios, for all acl types. Most configs I've seen test
> the same acl multiple times in a single request, which is why I
> think this is useful.

My main reason why I like this is because it solves a couple of ugly
race conditions, not as a method to improve performance.

For example, assume you have an external_acl lookup which you do not
want to have cached between requests (ttl=0). This does not work
without ugly hacks in the current code as the acl code assumes async
acl operations will be available in memory cache once completed.

We also have the other race condition where acl related data expires
or changes while a request is beeing processed. For exampel an ip
cache entry expires or changes between http_access and miss_access or
whatever. The same acl should evaluate to the same result for the
duration of the request, not "randomly" change opinion..

However I am not convinced it will allow you to save very much
performance as most acl checks is relatively fast to begin with. But
still I tink something like this is badly needed to clean up the ACL
code in a sane manner.

> We assign a unique numeric id to each acl as it is created (say
> from global pool), we can cache the results via a simple dynamic
> vector of the result types. On reconfigure we only reuse known free
> acl id's (which implies refcounting the id values, or some similar
> scheme).

I do not think refcounting is really needed. acls are only created
once and never destroyed.. A reconfigure only reloads the ACL data,
it does not destroy the actual acl.

Having the cache operate without change for the lifespan of the
request even during/after a reconfigure is probably preferable in my
opinion.

Regards
Henrik
Received on Tue Jan 28 2003 - 02:05:55 MST