ADFind udpate, stats and performance

Reading Time: 2 minutes

joe has released new version of excelent ADFind tool, You can read about this update and grab new version on joe's blog. I want to mention only one of the aspects of this update – on Windows 2008 (aka Longhorn) this version gives You access to new statistics for LDAP queries from AD.

Let's take a look at simple example:

adfind -b OU=Employees,DC=w2k,dc=pl -s subtree -f “objectClass=user” -stats+only

W wyniku otrzymujemy:

Statistics
=================================
Elapsed Time: 0 (ms)
Returned 1 entries of 2 visited – (50.00%)

Used Filter:
(objectClass=user)

Used Indices:
Ancestors_index:2:N

Pages Referenced : 46
Pages Read From Disk : 0
Pages Pre-read From Disk: 0

Analysis
———————————
Hit Rate of 50.00% is Ok

Indices used:

Index Name : Ancestors_index
Record Count: 2 (estimate)
Index Type : Normal Attribute Index
Ancestors Index used, possibly inefficient, verify filter.

Filter Breakdown:

(objectClass=user)

 

If You are familiar with stats in previous version of ADFind you will quickly notice the difference – in addition to filter breakdown and query efficiency we have now information about pages referenced by query, pages which had to be loaded form disk etc. This is additional information which can be useful in query optimization and performance analysis. Reading page from the disk is relatively slow operation compared to memory access, so if our query forces AD to read a lot of data from disk it may influence overall query performance.

When this might be important, for example when accessing attributes with long values. This is something which came out during the Eric's session on DEC 2007  and was addressed by Dmitri in discussion with audience. 

In ESE, which database engine utilized by AD, long values are stored in separated table. This means that if query will access attribute with long value it may require to read data from different area of database … which involves "slow" disk operation. Of course long values are cached as any others but for DC on which these values wasn't cached or memory size is not allowing to cache most of the data this may influence overall query performance.

With these new statistic information we can see this in the data. Then maybe we can try to reconsider number of attributes we are requesting from directory. Maybe instead of all attributes we should only request desired subset and some of those "long values" might be avoided.

On the side – for me such kind of information is something for what DEC is worth to attend but this is my personal feeling – maybe for others this is common knowledge 🙂

PS. As one might notice this query used objectClass=user filter and it used index – yes, objectClass is indexed in Windows 2008 by default.