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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature