Howard Chu wrote:

Michael Ströder wrote:

...

Still trying to optimize a bunch of set-based ACLs I wonder whether the (possibly heavy-weight) set-clauses in the <WHO> part are evaluated only in case of an actually matching <WHAT> part.

Any hint is appreciated.

Hint: OpenLDAP is the fastest, most efficient LDAP software in the world. Hint: Evaluating a clause that doesn't even match the target would be wasteful and inefficient.

Ok, I expected this but I wanted to really clarify. So thanks for confirming.

But I have to bother you with some more optimization questions. ;-) I'd be glad if you could comment my thoughts.

1. Order in <WHAT> clause -------------------------

Following your hints above: If the <WHAT> clause contains several statements one should put the simpler statements at first.

Example:

The ACL

access to dn.regex="^.+,cn=([a-z0-9]+),dc=example,dc=com$" attrs=userPassword filter="(&(|(objectClass=server)(objectClass=service))(status=0))" by [..]

should be optimized to

access to attrs=userPassword filter="(&(|(objectClass=server)(objectClass=service))(status=0))" dn.regex="^.+,cn=([a-z0-9]+),dc=example,dc=com$" by [..]

to defer evaluating the statements with higher costs to the end. Right?

2. (attr=*) -----------

It turned out that with my ACLs the OpenLDAP server's processing of (&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*)) is two times slower than just (objectClass=posixAccount). This seems to be independent of (pres-)indexing configuration of uid, uidNumber and gidNumber. It seems simply checking search privilege for those attributes is pretty costy.

3. Caching of set clauses -------------------------

Is there any caching of set clauses when processing a search request? Or are set clauses freshly evaluated when processing several ACLs?

In my ACLs set same clauses are used in several ACLs with different <WHAT> and I'm making use of "by * break" to make ACLs more readable. Ok, one should try to minimize the number of ACLs anyway but that's not always possible.

Ciao, Michael.