Case Study: Currently Directory service library is implemented via System.DirectoryService
What is how can we improve the performance of AD access?
Solution: using System.DirectoryService.Protocol and VLV
>>VLV work really well when you want to do a one-level search of an OU. In other cases it gives wrong total count and is not super fast.
>>Using the System.DirectoryServices namespace should be avoided it due to heavy pollution of ADSI COM weirdness, and a variety of other performance and flexibility reasons — preferring instead to use System.DirectoryServices.Protocols wherever possible.
>>Total number of record estimate is calculated accurate till 10,000 limit. Incase of VLV records are normally fetched as sliding window to, it works in most of the cases.
>> Multiple types of indexes can be created on same field.
>> Can we force client to create related to indexes, can affect other applications because of it.!!
Summary of Sample Data is at:
(With thanks to Steve Kradel)
1 Porting our architecture to System.DirectoryServices.Protocols then implement VLV based in the new namespace.
a, More efficient in terms of performance
b, More stable
a, Major redo of directory Service library is required.
2 Continuing to integrate System.DirectoryService based VLV to application.
a, It is the current implementation. So need little afford to implement VLV.
a, Not very efficient in terms of performance and stability.
1. Wrong Total Count:
Wrong number of total count is well known problem in searching domain.
Even in Google searching show the estimate number of pages. While searching, sometimes when you click on last pages, it shown nothing records and a custom message is shown. Basically in order to show fast results, search engine use approximation for total number of pages.
So paging can be shown on basis of estimate. When user clicks (try to go) on bad page (that does not exist) a user friendly message can be shown.
2. Navigation Style:
Navigation should be such that user moves from ou to ou and objects from only one ou are shown at time. In this way we can avoid the limitation of sub-tree search at a time. This type of navigation suits in most of the applications.
3. A warm up search with exact ldap query returning one record can serve the purpose of getting right number of records. It can solve the problem on getting right number of records. (A suggestion given by Steve Kradel [email: firstname.lastname@example.org ] )
4. A index creator screen is proposed that can help product admin to create and manage index for searching.
A careful and well analyzed index is very critical for performance of application. A bad index can kills the performance of other applications too.
Code of POC will be loaded soon.
“LDAP_UNAVAILABLE_CRIT_EXTENSION 0x0c Critical extension is unavailable.”