LDAP query performance

The other day I was having a discussion with a co-worker about Active Directory performance related to standard LDAP queries. The complaint (and basis for my involvement in the discussion) was based around poor LDAP performance, which was assumed to be attributed to LDAP queries hitting domain controllers contained within virtual machines. This assumption was based on the fact that some queries completed quickly while similar queries were much slower. After some discussion, and viewing the queries, I believed the problem to be more likely attributed to poorly designed queries, so I set off to prove this with actual data.

The queries included as part of this discussion were searching an attribute that was indexed and part of the partialAttributeSet (replicated to Global Catalogs). The queries that completed faster contained a specific value to search while the slow queries had multiple wildcards included in their value. To prove my hypothesis, I created a simple script to perform the same LDAP searches several times, some with specific values, some with a single wildcard and others with multiple wildcards:

[cc lang=”powershell”]
$report = @()
for($i=1; $i -le 5; $i++) {
$item = “” | select Count, SpecificValue, SingleWildcard, TwoWildcards
$item.count = $i
$item.SpecificValue = (Measure-Command { get-dn user mail “testuser@test.domain” }).TotalMilliseconds
$item.SingleWildcard = (Measure-Command { get-dn user mail “testuser*” }).TotalMilliseconds
$item.TwoWildcards = (Measure-Command { get-dn user mail “*tuser*” }).TotalMilliseconds
$report += $item
}
$report
[/cc]

*Note: Get-DN is a custom function created by a co-worker. It is a PowerShell function I have loaded in my profile that performs a global catalog search. It builds the LDAP filter using three arguments: 1.) the objectCategory to search 2.) the attribute to search 3.) the value to search for in attribute.

The results of the searchs can be seen below:

Count SpecificValue SingleWildcard TwoWildcards
----- ------------- -------------- ------------
    1        9.5489         9.3398   11066.8601
    2        7.7018          7.335   11102.0755
    3        7.8635         8.3801   11067.5442
    4        8.0664         7.6145   11137.9768
    5       10.2233         8.9622   11132.9646

The averages speak volumes about this test:

Property : SpecificValue
Average  : 8.68078

Property : SingleWildcard
Average  : 8.32632

Property : TwoWildcards
Average  : 11101.48424

As I expected, placing multiple wildcards in an LDAP search greatly impacts search performance — even if the attribute being searched is indexed. What I found somewhat surprising is that a single wildcard has nearly no impact on performance — actually in the test a single wildcard slightly outperformed the search of a specific value (but only by a fraction of a millisecond).

I performed these same queries several times and hard-coded the server names to search to include 1.) physical GC only 2.) virtual GC only 3.) allow DNS to resolve domain name to obtain GC name. Each result set was very similar (within fractions of milliseconds) so I included the default result set where DNS resolves the domain name to obtain a GC.

This article is filed under scripting (and not virtualization) because the results prove that using inefficient queries creates more impact on LDAP directory performance than whether you have physical or virtual domain controllers.

This entry was posted in Messaging, Scripting. Bookmark the permalink.

One Response to LDAP query performance

  1. Brent Quick says:

    Brian,

    I have had to do some basic LDAP work from time to time and more recently have been doing a lot of T-SQL queries so the multiple wildcard results being several magnatudes greater is not a supprise. As to the single wildcard and specific results being the same my guess is the amount of index that has to be read for both is the same but the second wildcard causes an explosion of combinations and those two joined values are not indexed.

    Thanks for taking up the defense of a VM as “not the problem, you the user are the problem!”

    Brent

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Notify me of followup comments via e-mail. You can also subscribe without commenting.