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
