performance problem with LDAP query

[nca]

I'm querying Active Directory with a simple LDAP query such as :
base: ou=persons,DC=mydir,DC=fr
filter: (myOrganization=ou=2001,ou=organizations,DC=mydir,DC=fr)
returning attributes : cn

Under ou=persons,DC=mydir,DC=fr, there are 62000 entries of the same
objectclass representing a person, having the attribute
myOrganization, which contains the DN of the organization of the
person

This query returns 116 persons entries as result. The problem is that
it takes approximately 10 seconds to answer (this time is the one
given in the LDAP event generated in the event viewer).
The myOrganization attribute is indexed (the box "Index this
attribute" is checked when browsing the Active Directory schema), so i
'd expect this query to answer almost instantaneously.

I have also activated more logs (see thread with subject "logs that
contains LDAP accesses to Active Directory" in this newsgroup, thanks
to Tony Muray for his response) and there is an event saying that the
62000 entries were "visited" and 116 were returned. So it seems that
the index is not used or is useless.

The strange thing is that a similar query with another indexed
attribute of the person class :
(mySite=cn=CRFG,ou=sites,DC=mydir,DC=fr), returns almost
instantaneously 21 entries and there is an event saying that 62
entries were scanned and 21 returned. So in this case the index is
used.

When comparing the two attributes myOrganization and mySite, wich are
both indexed, both of type Distinguished Name, the only difference is
that myOrganization is single-valued.

Is there a different behavior between single-valued and multi-valued
attributes ?
Are there some server parameters or thresholds that should be modified
?
Is there a known bug ?

Any help or comment is appreciated

Nicolas C.

 

[Klaas J.M. Langhout [MS]]

Nicolas,

This, is a very good question. I did some quick research and, did find an
article that states that the query time of an indexed multi-value attribute
will be slower than a single valued attribute.

This article also show's how to detect if a indexed attribute is used or
not.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/netdir/ad/indexed_attributes.asp


Hope this helps, Klaas

 

[Joe Richards [MVP]]

Could you download adfind from www.joeware.net on the free win32 c++ tools page and run the following commands and post
the results.

adfind -schema -f ldapdisplayname=myorganization

adfind -schema -f ldapdisplayname=mysite

I would like to see the configurations of those attributes.

 

[nca]

Could you download adfind from www.joeware.net on the free win32 c++ tools page and run the following commands and post
the results.

adfind -schema -f ldapdisplayname=myorganization

adfind -schema -f ldapdisplayname=mysite

I would like to see the configurations of those attributes.

First, thanks to Klaas. But note that the single-valued attribute is
the one which is problematic (query with a bad response time). So it
does not answer to my problem.

I must correct a little what i said. In fact, Active Directory seems
to use an index, because it generates an event saying it. Here are the
4 events that i get when I'm doing the query :
(myOrganization=ou=2001,ou=organizations,DC=mydir,DC=fr)

event 1: The directory is considering using index Ancestors_index to
optimize a query. The approximate record count for using index
Ancestors_index is 71297.
event 2: The directory has elected Ancestors_index as the optimal
index for this query.
event 3: The Search operation based at RootDSE
using the filter:
(myOrganization = <val>)
visited 62660 entries and returned 123 entries.
event 4: Internal event: Function ldap_search completed with an
elapsed time of 9969 ms.

Joe, here is the result with your nice tool.
I changed some real names to some more anonymous names (server and
attribute, ie myOrganization is not the real name of attribute) but
otherwise it is the exact output.
I hope you can find something interesting with these values.


C:\Program Files\Calendra>AdFind -schema -f
ldapdisplayname=myOrganization

AdFind V01.12.00cpp Joe Richards ([email protected]) May 2003

Using server: server001.annudev.fr
Base DN: CN=Schema,CN=Configuration,DC=annudev,DC=fr

dn:CN=myOrg-attribute,CN=Schema,CN=Configuration,DC=annudev,DC=fr

adminDescription: Organisation de rattachement
adminDisplayName: myOrg-attribute
attributeID: 1.2.840.113556.1.4.7000.233.28688.28684.8.33041.1684130.1439483.1488419.111
attributeSyntax: 2.5.5.1
cn: myOrg-attribute
instanceType: 4
isMemberOfPartialAttributeSet: FALSE
isSingleValued: TRUE
lDAPDisplayName: myOrganization
linkID: 10010
distinguishedName: CN=myOrgattribute,CN=Schema,CN=Configuration,DC=annudev,DC=fr
objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=annudev,DC=fr
objectClass: top
objectClass: attributeSchema
objectGUID: {EE4A7468-716F-4CF7-AC5C-905892A4CAEC}
oMObjectClass: 2B0C 0287 731C 0085 4A
oMSyntax: 127
name: myOrg-attribute
schemaIDGUID: {54260244-9EBB-49B8-98B6-9F20E6585EF0}
searchFlags: 1
showInAdvancedViewOnly: TRUE
uSNChanged: 4665372
uSNCreated: 2807
whenChanged: 20031006124322.0Z
whenCreated: 20020502142050.0Z

1 Objects returned

C:\Program Files\Calendra>AdFind -schema -f ldapdisplayname=mySite

AdFind V01.12.00cpp Joe Richards ([email protected]) May 2003

Using server: server001.annudev.fr
Base DN: CN=Schema,CN=Configuration,DC=annudev,DC=fr

dn:CN=mySite-attribute,CN=Schema,CN=Configuration,DC=annudev,DC=fr

adminDescription: ConcatΘnation des sites
adminDisplayName: mySite-attribute
attributeID: 1.2.840.113556.1.4.7000.233.28688.28684.8.33041.1684130.1439483.1488419.33
attributeSyntax: 2.5.5.1
cn: mySite-attribute
instanceType: 4
isMemberOfPartialAttributeSet: FALSE
isSingleValued: FALSE
lDAPDisplayName: mySite
distinguishedName: CN=mySite-attribute,CN=Schema,CN=Configuration,DC=annudev,DC=fr
objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=annudev,DC=fr
objectClass: top
objectClass: attributeSchema
objectGUID: {DEBC65C5-1040-4FC1-9015-634989400340}
oMObjectClass: 2B0C 0287 731C 0085 4A
oMSyntax: 127
name: mySite-attribute
schemaIDGUID: {B4C0CDC9-3AD4-4F52-9DEC-346227C164CB}
searchFlags: 1
showInAdvancedViewOnly: TRUE
uSNChanged: 2904
uSNCreated: 2904
whenChanged: 20020502142117.0Z
whenCreated: 20020502142117.0Z

1 Objects returned

Nicolas C.

 

[Joe Richards [MVP]]

Hmm that does seem a little off. I was hoping that the schema dumps would show up some detail that was "the key" but I
didn't see anything. I wonder now how efficient the DN attribute Indexing is.

--
Joe Richards
www.joeware.net