Re: Please comment

[GOMBAS Gabor <gombasg@inf.elte.hu>]

Hello,

> 3) Here's a neat test:  run a bunch of clients against four LDAP 
> servers that are identical except for one thing.  In one, use the ACL:

[...]

> What you'll see is that performance on the last three cases is about 
> the same, while the first case is *much* faster, relatively speaking.

Once I had some thoughts about caching ACL evaluations to speed things up.
Right now I'm bloated with work and have no time for OpenLDAP, so if you
like the idea, feel free to play with it.

1. Per-attribute ACLs can be stored with the AttributeDescription and not
in a global list. This can reduce the number of ACLs to check for each
attribute greatly and it eliminates the need to check for the attribute type
when evaluating ACLs. Only ACLs with no explicit attributes mentioned should
be stored in be->be_acl or in global_acl.

2. Implement a session cache for authenticated DN based ACLs. That is, for
an ACL "access <what> by <who>", evaluating "<who>" can be cached:

    if ( connection->acl_cache[ acl_to_check->id ].status == VALID ) {
	allow_mask = connection->acl_cache[ acl_to_chech->id ].allow;
	deny_mask = ...
    }
    else {
        /* evaluate the ACL and put the result into the cache */
    }

The cache should be wiped on bind and unbind operations. For the ideal case
this gives that expensive ACLs must be evaluated only once per (un)bind
operation (and not every time per attribute access).

3. If an entry someone has authenticated as gets cached, the ACL cache could
be stored with the entry; this way, if the user binds again the ACL cache
can be simply resurrected, so the "one evaluation per bind" can be enhanced
even more. In this case some form of cache time-to-live mechanism should be
implemented. If I'm right this would need backend support since the frontend
does not see the cached entries so implementing this method may require
deeper changes in the code.

If this last method is implemented, even the "<what>" part of the ACL could
be cached with the entry.

Determining if and how an ACL can be cached may require deeper analysis in
the ACL parse code. But it is a startup-time only cost therefore it's not
critical. The run-time cost is the additional memory needed to hold the
caches, but I don't think it would be too much.

Gabor

---
Gabor Gombas                                       Eotvos Lorand University
E-mail: gombasg@inf.elte.hu                        Hungary