Indexing
Indexing the appropriate attributes in CA Directory will increase the performance of search, update and remove operations in the directory server if done correctly. By default CA Directory will cache and index all attributes. If CA Directory is embedded in another product these defaults may be different. If CA Directory is believed to be the root cause of slowness then if you were to take a third party LDAP tool such as Jxplorer and attempt to connect to it and perform a search it would present the same scenario.
The only times the indexing needs to be reviewed is for:
Slow DSA start up times
When memory resources are tight on the machine (Recommend increasing system resources)
If some attributes have repetitive (weak) values: In this case, the performance of removing values can be improved. (Example: a lot of static groups assigned to each user)
The default cache-index command “set cache-index = all-attributes;” is added by when a DSA is created to the*.dxi file under $DXHOME/config/servers/<dsaName>.dxi.
The indexes are used when evaluating search filters so some candidate attributes for exclusion may be large BLOBs.
set cache-index Command -- Specify Attributes to Be Indexed
NOTE: Changes to the indexing configuration will require a restart of the DSA.
Release :
Component : CA IDENTITY SUITE (VIRTUAL APPLIANCE)
Indexing all-attributes - not best practice in large environments.
The primary attributes that you want to target for indexing are obviously the attributes that are searched frequently, but within that list, you need to only index the attributes that have unique values. Attributes that are in many entries in the directory which contain non-unique values (the same value in each entry) will not benefit from being on the index list. In fact, attributes with non-unique values will slow the directory performance. And remember that the larger the index list, the larger the DSA Memory footprint will be.
Attributes such as ‘uid’ (Unique Identifier) is a perfect choice for indexing because each entry will have a unique value in this field.
On the other hand, indexing the attribute “objectClass” - this is an attribute that may have the same value in all the entries of your user population. Think about millions of user entries in a DSA. Each of those entries will contain the identical name/value pair ‘objectClass = inetOrgPerson’. Any search, of this attribute will result into basically an index table scan of the entire entry list. Such attributes should never be searched as the sole attribute in a filter.
Example Search filters:
(objectclass = inetOrgPerson) – will be very slow with a very large result list
(&(uid = <userid>)(objectclass = inetorgperson)) – will be much more efficient
(uid = <userid>) – most efficient search
Remove Operations are the most expensive
Modify and Add requests to the entries in the directory not only update the actual entry in the directory, but will also update the indexes, so the more indexes that are configured, potentially the more time spent updating the indexes.
It may be a bit counter-intuitive, but the Remove operation is the most expensive operation. The reason for this is that when an entry is removed from the directory, the DSA will ‘clean-up’ the index for that entry. If we have configured non-unique attributes in our index list, the DSA will spend much time scanning the indexes to remove the appropriate indexes.
In environments with large number of entries and poorly optimized indexes lists, you may see Add operations taking 3-8 milliseconds, while Remove operations take 50-100 milliseconds.
General Rule
While each CA Directory implementations are unique with different requirements for indexing, there are a couple of general rules.
All RDN (naming attributes) attributes should be indexed
All attributes commonly searched by applications.
Some attributes we know immediately that will not be searched and can be removed from the index list. These are attributes such as ‘userPassword’, or any attribute that is an encrypted ‘blob’, like the attribute containing the CA SSO (SiteMinder) password data. If indexed these attributes are just taking up valuable space in Memory.
DISP Recovery indexes
Three attributes to add to the indexed attribute list, mandatory if you have configured ‘set multi-write-disp-recovery = true;‘. These attributes are operational attributes that are utilized by the DSA when it is in DISP recovery mode (searching itself for updated entries from a certain time point).
set cache-index = modifyTimestamp, dxDeleteTimestamp, createTimestamp, . . .;
CA Directory Indexes require no maintenance
Since all indexes are built in memory at startup, and maintained in memory during operation, they are never persisted to disk. This means that the CA Directory indexes require no maintenance – no tuning.
If the indexing list needs to be changed, simply change the data DSA .dxi file and restart the directory server.
DXconsole to help determine index list
DXconsole is a tool that allows for real-time view of configuration and statistics, and also allows some configuration to be changed real-time.
To initiate the DXconsole, ‘telnet localhost consolePort#’. The console port number is configured in the DSA knowledge configuration file.
Using the ‘get cache’ command, the list of configured attributes will be displayed. Along with each of the attribute names, next to each attribute is also displayed the number of entries containing the attribute, the number of unique values for the attribute and the number of times the attribute has been searched.
Review this information to determine the most effective attribute list for indexing.
Example Index Configuration:
Below is an example of index configuration, notice I commented out the “all-attributes” line and added the list of attributes to index. This is just an example.
Edit the $DXHOME/config/servers/<dsaName>.dxi file
# set cache-index = all-attributes;
set cache-index = modifyTimestamp, dxDeleteTimestamp, createTimestamp, ou, cn, sn, uid;