LDAP Directory servers are designed to process search queries at the speed of light (almost).

But sometimes, the search queries issued by a client application are not as fast as expected. This often comes from an indexing misconfiguration or problem, but finding the root cause is not easy. I should say WAS not easy.

The OpenDS LDAP directory server supports a “magic” operational attribute that allows an administrator to get from the server information about the processing of indexes for a specific search query: debugsearchindex.

If the attribute is set in the requested attributes in a search operation, the server will not return all entries as expected, but a single result entry with a fixed distinguished name and a single valued attribute debugsearchindex that contains the information related to the index processing, including the number of candidate entries per filter component, the overall number of candidate, and whether any or all of the search is indexed.

$ bin/ldapsearch -h localhost -p 1389 -D “cn=Directory Manager” -b “dc=example,dc=com” “(&(uid=user*)(mail=joe*))” debugsearchindex

Password for user ‘cn=Directory Manager’: *********

dn: cn=debugsearch

debugsearchindex: filter=(&(uid=user*)[COUNT:100](mail=joe*)[INDEX:mail.equality][COUNT:0])[COUNT:0] final=[COUNT:0]

$ bin/ldapsearch -h localhost -p 1389 -D “cn=Directory Manager” -b “dc=example,dc=com” “objectclass=*” debugsearchindex

Password for user ‘cn=Directory Manager’: *********

dn: cn=debugsearch

debugsearchindex: filter=(objectClass=*)[NOT-INDEXED] scope=wholeSubtree[COUNT:102] final=[COUNT:102]

./ldapsearch -h localhost -p 1389 -D “cn=Directory Manager” -b “dc=example,dc=com” “mail=user.1*” debugsearchindex

Password for user ‘cn=Directory Manager’: *********

dn: cn=debugsearch

debugsearchindex: filter=(mail=user.1*)[INDEX:mail.substring][COUNT:11] scope=wholeSubtree[COUNT:102] final=[COUNT:11]

Technorati Tags: directory-server, ldap, opends, opensource, tip