Howard Chu wrote: 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.