[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: problems with big groupOfNames entries

"Kurt D. Zeilenga" wrote:

> At 07:15 PM 11/20/99 -0700, Jeff Romine wrote:
> >
> >Hi all,
> >
> >We were planning to use groupOfNames entries in our system
> >for several reasons:
> >
> >1. Use of  the "group=" construct in ACLs
> >2. Using groupOfNames to group users into
> >roles, departments, mailing lists, etc, seems
> >much more manageable than using the DIT
> >structure for this purpose.
> >3. Browseability (is that a word?)
> >
> >This worked great until some of our groupOfNames entries
> >got large and then we discovered that several operations have
> >execution times which are directly proporitional to number
> >values in the member attribute. These operations include
> >(and there are probably more):
> >
> >1. Adding a value to the member attribute.
> >   When you do this slapd touches every attribute value
> >   at least twice, (3 times if the entry isn't cached). Once to
> >   make a duplicate of the attribute set and once to verify
> >   that the value isn't already present.
> >
> >2. Checking an ACL with a "group=" clause.
> >   This does a linear search through the values.
> >
> >Oh yeah, and indexing on member doesn't help a bit in
> >these situations.
> Indexing member is likely the root cause of the problem.
> Each time you update member, the indices for member must
> be updated.  If you have many values of member, this
> gets expensive.
> In such cases, you might find it better not to index member.


This is not the primary problem.  It may help slightly to remove
the index in the case of adding  new values, but it definitely won't
help with using the group construct in ACLs.  This makes the
group= construct almost useless in even moderately large
systems.  Besides, even without indexing, the performance of
adding values to large groupOfNames entries will still be poor
and will still be linearly related to the number of values.

-Jeff Romine