Ok, I've finally had time to sketch out acl result caching. Here's the top level concept: If we: *) Alter the acl checking code to store the result (match, no-match, unknown, in-progress) of an acl check in a cache. *) Alter the acl checking code to use the results of an acl check from cache if possible. *) define an acl result cache as an associative array (more later on this). *) Create optional cache parameters to the acl checklist checks (noth NB and vanilla). If the cache is not provided, an interim one is created. *) Add an acl cache to the clientHttpRequest struct and use it in acl check calls.
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. Design sketch: 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). If anyone is interested, I'd be happy to code up a stats gathering patch, to roughly estimate the impact a caching scheme could have, without actually implementing one (and therefor having to get it right :]). Rob -- GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.
signature.asc
Description: This is a digitally signed message part
