[Date Prev][Date Next]
Re: ACL Performance (caching on object basis) (ITS#1523)
On Friday, 1. February 2002 22:41, Kurt D. Zeilenga wrote:
> At 11:10 AM 2002-02-01, Howard Chu wrote:
> >I've looked thru it, there are still some details that could be
> >cleaned up. I think this code does too much work if all you want
> >is to speed up send_search_entry, and there is a simpler way to
> >accomplish that, as Kurt has described in previous posts.
> I worked up a patch to demonstrate the approach I'm advocating.
> Consider this a prototype, I haven't had time to think
> through all the cases nor run much more than test006
> against it.
> The advantages of this approach are:
> very little change to access_allowed() callers
> (even those who provide a state structure)
Well, the change to the access_allowed callers is not much bigger in case of
my patch (my structure needs to be destroyed, yours doesn't)
> no additional malloc/free calls
Yes, that's clearly the advantage of your approach.
> no additional loops
The only additional loops that my patch introduces are through the already
evaluated ACLs. Since your patch does only store one of those, you don't need
to loop. In my case, if only one ACL applies to the object, the loops become
rather short. If more than one ACL applies to the object my code is likely to
be faster than yours, because it will have to loop through already evaluated
ACLs while your code most probably needs to re-evaluate ACLs. (Your code will
be faster if the backend sends the attributes in the right order, but I don't
see how it could accomplish this).
> only addresses common read scenarios,
> some modify scenarios will not be benefit
> (e.g. modify: delete/member/value + add/member/value)
well there is on other scenario that will not benefit:
imagine the following acls:
access to attr=a,c,e,g,i,l by dn="uid=blabla" read;
access to attr=b,d,f,h,j,k by dn="uid=blubblub" read;
and the object contains all these attributes (returned in the order
With your approach you will have to evaluate 11 ACLs, with my approach 2 (and
with the original code 24).
Stephan Siano Mail: Stephan.Siano@suse.de
SuSE Linux Solutions AG Phone: 06196 50951 31
Mergenthalerallee 45-47 Fax: 06196 409607