Problem

A Forum reader recently asked:

"I am seeing hideously bad search performance under eDir 8.7.3.9. We search an entire context / branch of the tree periodically, as frequently as every 30 seconds, but typically no less frequently than every 10 minutes. The code has to do this brute force as we cannot use DSEvents, and we cannot use the LDAP events methods as we need backwards compatibility to
the stone age."

And here's the response from eDirectory expert Jim Henderson ...

Solution

Subtree searches in 8.7.x are going to be a bit slower; you'll get better performance from 8.8 if that's an option for you. There was a change in how the search algorithm is applied that provides significant performance improvement on subtree searches where the subtree is a small section of the whole.

Also check your index configurations on the servers handling the search - this would include servers that would be referred to. If the attribute isn't indexed, add one for it.

Presence indexes aren't used by searches - that type is only used by internal processes. You have to use a value or substring index. With those data types, you may have to fiddle a little bit to determine which index type provides you with the best performance.

It's sometimes easy to forget to hit other boxes; just remember that indexes are server-centric and only apply to local data.

In 8.8, there was another attribute added to the Top class called "Ancestor ID". This is similar to the parent entry ID attribute, but it holds all objects that are superior to the object in question.

With 8.7.x and earlier, searches with a scope of "one" are really fast because the Parent attribute can be searched using an index. But with subtree searches, that doesn't work because eDirectory doesn't know all the parent objects all the way to [Root] - so a subtree search needs to filter first by other attributes, and then each object is evaluated for whether or not it falls in the subtree. This can be pretty slow if you have lots of objects and are scoping to a small subtree.

With 8.8, we use Ancestor ID to determine the subtree, so if the subtree is relatively small (there's some intelligence in which algorithm to use - the old one or the new one), we can reduce the set of objects that the other filters are to be applied to. This speeds the search up significantly, and it can give subtree searches performance that's close to the "one" search scope.