Re: ACL Performance (caching on object basis) (ITS#1523)

[stephan.siano@suse.de]

Hi,

On Friday, 8. February 2002 08:07, Kurt D. Zeilenga wrote:
> The approach I suggested was designed specifically to address
> the common case which you raised at the top of this thread.  That
> is, speeding up value independent ACL evaluation for attributes
> with large number of values.  The approach, I believe, adequately
> addresses this and a number of other common cases with very
> little overhead.  In particular, I do not see any case where its
> performance would be worse than the existing code.

Actually I was originally addressing two problems, one with a large number of 
values in one attribute (which is addressed by your patch) and another with a 
large number of attributes where the same ACLs apply. The latter case is not 
handled by your patch (initially I thought it did address this case, however 
your state structure is cleared each time the attribute changes).

> With your approach, it appears that cache management overhead,
> in particular the extra malloc/free calls, may offset whatever
> benefit the cache might offer.  I believe further performance
> analysis is needed to determine whether your approach will be
> generally useful or not. I encourage you and others to undertake
> such analysis as this may demonstrate your suggested approach
> is viable.

OK the problem with the performance analysis is to weight a malloc/free pair 
against a ACL evaluation (the cost of latter depends strongly on the kind of 
the ACL that needs to be evaluated multiple times). However I have found a 
less aggressive approach that avoids mallocs at all. It extends the 
AccessControlState struct by a pointer to a value independant AccessControl 
and a pointer to the AttributeDescription of the attribute where the Access 
Control applies. 

If the AttributeDescription is different from the one stored in the 
AccessControlState but the access control is the same (and value 
independant), the access control result from the state is returned.

> In the meantime, I propose that my suggested patch be committed.

I have uploaded the patch to 
ftp://ftp.openldap.org/incoming/stephan-siano-20020229.patch
(huh, I hnow it's not a leap year, but i mistyped the date at the ftp...).

Yours
Stephan Siano

-- 
Stephan Siano                           Mail:  Stephan.Siano@suse.de
SuSE Linux AG                           Phone: 06196 50951 31
CU PS DU South TCC UC                   Fax:   06196 409607
Mergenthalerallee 45-47	
D-65760 Eschborn