(Note: this is the first of a 4 part post).
In previous posts, I raved about .NET’s System.DirectoryServices (S.DS) — its library for accessing LDAP directories. In this post, I’ll go over how I sped up a particular bit of S.DS code in dramatic fashion.
S.DS, like any code, needs to be used and studied for a while before you really become adept at understanding how best to use it. If used in poor fashion, it can result in very slow code.
In my case, the slow code arose from my desire to properly layer various components of our software. Although n-tier design (where, most often, n=3) is associated with database processing the fundamental concept can be used on just about any software. The general idea behind tiered design is to isolate components from the details of other components “above” or “below” them in hierarchy. In database software, n-tier design suggests that all database access (connecting to the database, executing SQL statements) be performed in the data layer and that no other layer be aware of how the data is stored in the database. This allows you to change a database schema, for example, and to only have to change the one layer.
Atop the database layer, a business rules layer is often present. This layer contains the main program logic. In a banking application for example, it’s the layer that knows that a transfer between accounts involves a transacted withdrawal from one account and deposit to another.
Finally, the user interface layer displays information to the user and allows the user to initiate actions.
In my S.DS application, I use a similar layering. Only the data layer knows how Likewise stores information in AD. The data layer exposes higher-level UserInfo, GroupInfo and CellInfo objects that are manipulated by the business-rules layer. Finally, the user-interface layer is the code that interacts with our MMC snapins or with our own Likewise Console.
This layering initially resulted in some very slow code during a very common use case. When the user brings up the Likewise Settings property page for an AD organizational unit (OU) — in Microsoft’s Active Directory Users and Computers (ADUC) snapin — we display a list of all of the users and groups that are “enabled” for Unix access by the computers joined to that OU. At the lowest level, this operation starts with an AD search performed by the S.DS DirectorySearcher class. At the UI level, the data is displayed in a ListView.
When we encountered an OU with a large number of users and groups (around 10,000), my original implementation of this code took 20 minutes (1200 seconds) to display the information. By the time I finished redesigning and optimizing, I had this time down to less than 20 seconds.
I’ll explain how I accomplished this in my next post.