Comparing AD custom classes to AccountManagement

When developing code for an Intranet setting, where users must log in to be granted access to a client computer, it is often best practice to utilize Active Directory to obtain user information for your application. This saves administrators from having to maintain and update a separate user database in SQL or otherwise. Though this is an easy route to take to take while your network is small, it will become increasingly difficult to keep a separate user database as your user base grows.

Recently, I had to switch some existing web based applications from an SQL common user database onto active directory. To say the least, calls to the SQL user database were used liberally. Initially, I didn’t think anything of it, and simply switched the code in the data access layer of the application to get the info I wanted from AD instead of SQL queries.

In testing, the application proved to be very slow, taking literally minutes to load each page. I had to assume that the problem existed within the LDAP queries to AD. I started to do some research and read that the classes I had written using the System.DirectoryServices namespace (had to be compatible back to ASP.Net 2.0) were now available in ASP.Net 3.5 in the System.DirectoryServices.AccountManagement namespace. I decided to set out to see if these new classes would be more efficient than my own hand written ones. I do have to say one thing; the code is much easier, no more clunky strings with LDAP queries. Code that once looked like this:

Now looks like this:

Though not terribly impressive for getting a user by login name, the ease of getting groups is much more pronounced over the older DirectorySearcher methods. Makes me wish I didn’t spend all the time figuring out the LDAP queries for these things, though many were available via web searches.

In order to see if the queries were going to be more efficient, I took advantage of an existing test harness I had prepared for my old ASP.Net 2.0 AD classes. I wrote a few new methods using the AccountManagement namespace that would return comparable information, such as the two get user by login methods. One test harness compared the UserPrincipal, the other compared the GroupPrincipal. A summary of the tests are bulleted below.

• Test harness was utilized to analyze time taken for multiple calls to active directory.
• For loops were utilized with both 30 and 60 calls to AD.
• Difference was taken between the time before the for loop and after the for loop to quantify the total time for the loop to execute.
• Comparison of my classes to those of the System.DirectoryServices.AccountManagement which is built into ASP.Net 3.5 & 4.0

The results are detailed in the charts below.

• My classes are 42-46% faster for returning the User
• My classes are 20-22% slower for returning the Group
• Either way, access to AD is incredibly slow and expensive!

The result is that weather I use my classes or the new AccountManagement classes, getting info from AD is slow. Though I have searched, I have been unable to find exactly why the queries are so slow. Making a long story even longer, I decided to go with the AccountManagement classes for 2 reasons. One, I am lazy and hopefully Microsoft will make the underlying classes faster with coming releases of the framework. Two, the GroupPrincipal is much faster than my own methods for retrieving group info, and the majority of what I do is checking to see if a user is in a group. I only have to get the user once, but I have to go get group membership info more regularly.

A partial solution to the inefficiency of these queries is to get the majority of the information you need all at once, and store it in session state. It seems that it is more efficient to go get a ton of data from AD and stash it away somewhere than to repeatedly go get little tidbits of data. I typically create a session wrapper class to keep my session variables strongly typed, but that is for another blog entry.