LDAP queries can be a bottleneck in a heavily utilized directory-server environment. To maintain a high level of performance with large numbers of objects, create indexes for the attributes that are frequently used in Identity Vault searches. An index is a set of keys arranged in a way that significantly speeds up the task of finding any particular key within the index. This allows to efficiently retrieve the objects whose attributes are indexed during searches without having to search the entire database every time a search is issued. When a complex query is run against objects with indexed attributes, the query returns relatively faster.
The Identity Vault ships with a set of indexes that provide basic query functionality. These default indexes are for the following attributes:
Aliased Object Name cn dc Equivalent to Me extensionInfo Given Name GUID ldapAttributeList ldapClassList Member NLS: Common Certificate Obituary Reference Revision Surname uniqueID uniqueID_SS
When you install Identity Manager, the default directory schema is extended with new object class types and new attributes pertaining to Identity Applications. The Identity Applications specific attributes are not indexed by default. For better performance, you might find it useful to index some of those attributes (and perhaps a few traditional LDAP attributes as well), particularly if your user container contains over 5,000 objects.
The general idea is to index only those attributes that you know are regularly queried, which could be different attributes in different production environments. If you already know which attributes you are likely to use in your searches, you must index those attributes. For example, if you know that users of your org chart are likely to perform searches based on the isManager attribute, you can try indexing that attribute to see if the performance is enhanced.
NOTE:As a best practice, it is recommended that you index, at a minimum, the manager and isManager attributes.
Indexes can be of type presence, value, and substring indexes.
Value matches the entire value or the first part of the value of an attribute. For example, value matching could be used to find entries with a LastName that is equal to “Jensen” and entries with a LastName that begins with “Jen.”
Presence requires only the presence of an attribute rather than specific attribute values. A query to find all entries with a Login Script attribute would use a presence index.
Substring matches a subset of the attribute value string. For example, a query to find a LastName with “der” would return matches for Derington, Anderson, and Lauder. A substring index is the most resource-intensive index to create and maintain.
A compound index is a new type of index. You can think of it as a value index on more than one attributes. It stores the values of the attributes as part of the key for the index. For more information, see Enabling Compound Index on Identity Vault Attributes.
The type of index you create, depends upon if the search is looking for any value (*), or a specific value such as person or admin. For example, use a presence index when a * is used in the query. Use a value index when a specific value is used in the query. Although indexes improve search performance, additional indexes also add to directory update time. As a general rule, create new indexes only if you suspect performance issues are related to a particular directory lookup.You can create, manage, and delete indexes in iManager (eDirectory Maintenance > Indexes). For more information, see “Index Manager” in the eDirectory Administration Guide.
For more information about eDirectory performance tuning, see “Maintaining eDirectory” in the eDirectory Administration Guide.