RE: ACL performance tuning suggestions

["Howard Chu" <hyc@highlandsun.com>]

I have some patches I've been testing that cache the results of group
membership resolution. Since it caches the result code, it includes
"present" and "not present" so it's very effective. However, my testing has
turned up some other odd situations in the ACL code which I am still
investigating. (It appears to do multiple/redundant evaluations of some
clauses for an entry.)

>>>
-----Original Message-----
From: OpenLDAP Mailing List [mailto:openldap@kogz.com]

Howard,

With a single backend and an equlality index on "member" attribute, group
membership resolution would be very quick. It would be nearly as fast as any
ONE of the group checks done "on the fly" (in my case dozens of times per
query).

I concur that some sort of algorithm would need to be designed to determine
when this prefetch (and any other caches or prefetches) would be a net gain.
I agree completely that such a simple algorithm would not be universally
applicable, but it would be handy thing to have in the bag of tricks for
certain environments (like mine). Many situations would be paying a penalty
for no gain whatsoever but others could improve an order of magnitude or
more.

Some other possibilities I have thought of:

1. Break out the "type" of operation to allow optimizations for different
actions (BIND, READ, MODIFY, CREATE). For example, user objects can be quite
complex in certain environments (can change this, not that, can't see this,
can see that, etc.) but are used very commonly as bind opertators. A clause
like this would improve bind performance greatly for me:

access to *
       operation=bind
        by * auth

Without this, I need to evaluate 3 ACL clauses just to bind a user which is
a very common occurence. Similare constructs could grant READ access very
simply before complex WRITE / ADD operations would be defined. This
structure could optimize the use model of the data with the ACL defitions
and allow non-standard (admin, etc.) fuctions to not slow down day-to-day
use.

2. Return and cache all attributes granted by a clause. If an operator needs
3 attributes from an object that are all granted by the same clause, 3
iterations are still required to resolve, each iteration looping through x
number of group membership checks. The first response could return the mask
and the list of all attributes sharing the same maks, speeding up

3. cache grants to [entry]. Per-attribute masks change frequently, but I
notice many attempts to resolve permissions to the same [entry] occuring
several times per session. Since entry is usually one of the last things to
be defined in an ACL def, its resolution can be very expensive.

4. Cache the "who" for each clause. After the "who" has been determined in a
clause (given the operator), remember which "who" I am for that session.
"who" resoultion can be costly to resolve.

5. Cache who I am NOT. If prefecting group membership is not applicable, it
would still be great to know that a user is not in the admin group after
checking this for the first time. Caching group-non membership would be very
helpful.

I hope to start working on these in about a month. I won't have any time
before then.

Kevin
<<<

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support