[Date Prev][Date Next]
problems with big groupOfNames entries
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. This isn't too bad with moderately sized
groupOfNames entries but when you get to 20,000 or so
things get pretty dismal.
I can think of several potential ways of fixing this (the
all involve special-casing groupOfNames entries)
1. Maintain the member values in more search friendly
2. Make use of the index (sort-of the same as 1)
I'm open to suggestions and am also willing to work on