There are several problems with this idea:
a) it is not possible to predict at bind time which backends you
should
search to see what groups contain a particular bind DN. Without this
knowledge, you're forced to search all backends, which is hardly an
optimization.
b) even if it were possible, it would take a long time. This would
make
binds very slow.
Howard,
With a single backend and an equlality index on "member" attribute,
group membership resolution would be very quick. It would be nearly as
fast as any ONE of the group checks done "on the fly" (in my case dozens
of times per query).
I concur that some sort of algorithm would need to be designed to
determine when this prefetch (and any other caches or prefetches) would
be a net gain. I agree completely that such a simple algorithm would not
be universally applicable, but it would be handy thing to have in the
bag of tricks for certain environments (like mine). Many situations
would be paying a penalty for no gain whatsoever but others could
improve an order of magnitude or more.
Some other possibilities I have thought of:
1. Break out the "type" of operation to allow optimizations for
different actions (BIND, READ, MODIFY, CREATE). For example, user
objects can be quite complex in certain environments (can change this,
not that, can't see this, can see that, etc.) but are used very commonly
as bind opertators. A clause like this would improve bind performance
greatly for me:
access to *
operation=bind
by * auth
Without this, I need to evaluate 3 ACL clauses just to bind a user which
is a very common occurence. Similare constructs could grant READ access
very simply before complex WRITE / ADD operations would be defined. This
structure could optimize the use model of the data with the ACL
defitions and allow non-standard (admin, etc.) fuctions to not slow down
day-to-day use.
2. Return and cache all attributes granted by a clause. If an operator
needs 3 attributes from an object that are all granted by the same
clause, 3 iterations are still required to resolve, each iteration
looping through x number of group membership checks. The first response
could return the mask and the list of all attributes sharing the same
maks, speeding up
3. cache grants to [entry]. Per-attribute masks change frequently, but I
notice many attempts to resolve permissions to the same [entry] occuring
several times per session. Since entry is usually one of the last things
to be defined in an ACL def, its resolution can be very expensive.
4. Cache the "who" for each clause. After the "who" has been determined
in a clause (given the operator), remember which "who" I am for that
session. "who" resoultion can be costly to resolve.
5. Cache who I am NOT. If prefecting group membership is not applicable,
it would still be great to know that a user is not in the admin group
after checking this for the first time. Caching group-non membership
would be very helpful.
I hope to start working on these in about a month. I won't have any time
before then.
Kevin
-----Original Message-----
From: Howard Chu
Sent: Fri 11/2/2001 7:57 PM
To: OpenLDAP Mailing List
Cc: openldap-software@OpenLDAP.org
Subject: RE: ACL performance tuning suggestions
There are several problems with this idea:
a) it is not possible to predict at bind time which backends
you should
search to see what groups contain a particular bind DN. Without
this
knowledge, you're forced to search all backends, which is hardly
an
optimization.
b) even if it were possible, it would take a long time. This
would make
binds very slow.
c) caching of this form creates a subtle change in behavior -
currently,
if the membership of a group is changed during the life of a
session, that
change will be picked up the very next time the group is
referenced in an
ACL check. It might make sense to just cache memberships at bind
time, and
ignore any group changes that occur after the bind, but you have
to be aware
of this different behavior and accept that this is what you
want. This could
become an extreme problem for your example of long-lived
sessions, but it's
difficult to foresee.
Still it would be good to see improvements in this area. I have
some ideas
on
the problem that I'm testing out currently.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
>>
-----Original Message-----
>From: owner-openldap-software@OpenLDAP.org
[mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of
OpenLDAP Mailing
List
well, what abour pre-resolving group membership at bind time?
that would be
a HUGE performance gain for certain queries (like building large
result sets
of ACL data and doing iterative queries), especially for
long-lived handles.
I think that would be simple and a good first step.
You could then remove all of the ldbm_back_group calls and match
directly
against a small list in RAM.
Kevin
<<
<<winmail.dat>>