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

Re: problems with big groupOfNames entries



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.