HI!
Frankly I forgot whether I asked this before:
Let there be ACLs with dn.regex="..", attrs=foo,bar and val.regex=".." in the <what> clauses.
Obviously depending on complexity of regex-pattern and length of DNs / avals the regex checking is more expensive than equality checking of attrs=.
Can I improve ACL performance by order of <what> clauses or are they processed in fixed order anyway? If in fixed order, which one?
Ciao, Michael.
Michael Ströder michael@stroeder.com schrieb am 11.08.2021 um 16:36 in
Nachricht be6c4c4c-2c0d-bc8f-67fd-b640a7026ccd@stroeder.com:
HI!
Frankly I forgot whether I asked this before:
Let there be ACLs with dn.regex="..", attrs=foo,bar and val.regex=".." in the <what> clauses.
Obviously depending on complexity of regex-pattern and length of DNs / avals the regex checking is more expensive than equality checking of
attrs=.
Can I improve ACL performance by order of <what> clauses or are they processed in fixed order anyway? If in fixed order, which one?
I don't know what regex library slapd uses, nor do I know whether slapd caches compiled regex, but both could be important. If you know what regex library it is, you could try different regex in a stand-alone testing program to find out what costs most performance. However my guess was that on modern machines regex performance shouldn't matter unless the regex needs some unbounded look-ahead or backtracking. I'd be surprised if any is needed in LDAP ACLs.
Maybe you give an example of your regex?
Regards, Ulrich
Ciao, Michael.
Michael Ströder wrote:
HI!
Frankly I forgot whether I asked this before:
Let there be ACLs with dn.regex="..", attrs=foo,bar and val.regex=".." in the <what> clauses.
Obviously depending on complexity of regex-pattern and length of DNs / avals the regex checking is more expensive than equality checking of attrs=.
Can I improve ACL performance by order of <what> clauses or are they processed in fixed order anyway? If in fixed order, which one?
The order is fixed, in order of increasing granularity. DN first, attribute next, value-specific last. That is the only order that makes logical sense.
On 8/13/21 1:51 AM, Howard Chu wrote:
Michael Ströder wrote:
HI!
Frankly I forgot whether I asked this before:
Let there be ACLs with dn.regex="..", attrs=foo,bar and val.regex=".." in the <what> clauses.
Obviously depending on complexity of regex-pattern and length of DNs / avals the regex checking is more expensive than equality checking of attrs=.
Can I improve ACL performance by order of <what> clauses or are they processed in fixed order anyway? If in fixed order, which one?
The order is fixed, in order of increasing granularity. DN first, attribute next, value-specific last.
Is this order implemented in function slap_acl_get() in acl.c?
The last seems to be filter= after val=. Right?
That is the only order that makes logical sense.
Why?
IMHO attrs= should be checked first because
dn.regex=".." val.regex=".." filter=".."
are all potentially way more CPU-intensive than checking attrs= against a simple hash-map.
Ciao, Michael.
openldap-technical@openldap.org
-
Howard Chu -
Michael Ströder -
Ulrich Windl