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
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.
should be optimized to
to defer evaluating the statements with higher costs to the end. Right?
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
to minimize the number of ACLs anyway but that's not always possible.