Directory Programming .NET

Active Directory and ADAM programming support for .NET developers
Welcome to Directory Programming .NET Sign in | Join | Help
in Search

FindAll Poor Performance Revisted...

Last post 07-02-2008, 11:36 AM by joe. 1 replies.
Sort Posts: Previous Next
  •  07-02-2008, 9:41 AM 4087

    FindAll Poor Performance Revisted...

    I found on old thread on this forum titled "FindAll Poor Performance".

    The issue I was experiencing was that the call to the FindAll method seemed to respond immediately when using the development server in the Visual Studio environment but seemed to respond slowly (about 10 or 15 seconds) when using IIS.

    After reading the thread mentioned above, I noticed that there were some additional AuthenticationTypes (namely FastBind and ServerBind) that were being used.  I have never used these so I figured I would give it a shot (I figured it couldn't hurt which is how I start thinking when I get desperate).  To my surprise, this actually fixed the issue.  Now both environments respond very quickly.

    The question I have is what did I actually do by specifying the additional AuthenticationTypes values?

    Thank you,

    Jason

  •  07-02-2008, 11:36 AM 4088 in reply to 4087

    Re: FindAll Poor Performance Revisted...

    We talk about these in the book.

    ServerBind is a flag you should always use when you are connecting to a specific server (have full DNS Name of DC in the ADsPath) but should never use if you are not.  Essentially, ServerBind flag tells LDAP not to do an additional DNS lookup/locator call to try to resolve your name to a server and just tries to connect directly.  Depending on the perf cost of doing that locator call, that might be noticable.

    Make sure that you don't use this flag if you need locator support though!  One thing you can do is use the locator support in S.DS.AD to get the name of a DC to use and then use that directly in other calls later or just use S.DS.AD for getting references to DirectoryEntry objects.

    FastBind tells ADSI to skip its initial check of a given object to find its objectClass.  By default, ADSI will perform a base search on any IADs object (which the DirectoryEntry wraps) to get its objectClass.  ADSI needs this in order to know what additional ADSI COM interfaces to make available to COM clients beyond the core interfaces that apply to everything.  For example, ADSI will make IADsUser available on an object if it knows the object is a user.

    However, if you don't need the additional IADs interfaces, this extra search is a real perf hit.  With S.DS, you almost never need these interfaces, so in general using FastBind can help a lot.  For example, you only need IADsUser if you need to invoke one of the IADsUser like SetPassword.

View as RSS news feed in XML