DirectorySearcher first access speed

Discussion in 'ASP .Net' started by cameron, Nov 24, 2004.

  1. cameron

    cameron Guest

    I have always been under the impression that LDAP was optimized for
    speed. Fast queries, fast access, slower writes. I have a block of data
    in LDAP and in SQL. Exact same data. The query is fast but the first
    access to the result set takes longer that to do the query in SQL and
    process the sql results.

    From my trace.axd
    LDAP Test Starting Search 0.000112 0.000043
    LDAP Test Done Search 0.003821 0.003374 <--- fast query at .003 sec
    LDAP Test Build XML Doc 0.003906 0.000086
    LDAP Test For Loop 0.461937 0.458031 <-- The top of the for loop


    Trace.Write(Name, "Build XML Doc");
    for(int i=0; i<Results.Count; i++)
    {
    Trace.Write(Name, "For Loop");
    .....

    I have traced this down to the 'Results.Count' code. If I loop through
    it in some other way then the first access into the search results then
    takes the nasty hit. No matter what the access is, (the count or a
    single property on a SearchResult object). I have re-arranged the loop
    that goes through this result set a couple of different ways and
    whatever does the first access into the data takes the at least a .44
    sec hit.

    Does anyone know what I am doing wrong?

    -Cam
    cameron, Nov 24, 2004
    #1
    1. Advertising

  2. cameron

    bruce barker Guest

    actually LDAP is fast lightweight protocol for talking to a directory
    service. this does not imply the directory service is fast. if you are
    quering an active directory service, you may have performance problems
    unless the AD has been tuned.

    -- bruce (sqlwork.com)



    "cameron" <> wrote in message
    news:...
    | I have always been under the impression that LDAP was optimized for
    | speed. Fast queries, fast access, slower writes. I have a block of data
    | in LDAP and in SQL. Exact same data. The query is fast but the first
    | access to the result set takes longer that to do the query in SQL and
    | process the sql results.
    |
    | From my trace.axd
    | LDAP Test Starting Search 0.000112 0.000043
    | LDAP Test Done Search 0.003821 0.003374 <--- fast query at .003 sec
    | LDAP Test Build XML Doc 0.003906 0.000086
    | LDAP Test For Loop 0.461937 0.458031 <-- The top of the for loop
    |
    |
    | Trace.Write(Name, "Build XML Doc");
    | for(int i=0; i<Results.Count; i++)
    | {
    | Trace.Write(Name, "For Loop");
    | ....
    |
    | I have traced this down to the 'Results.Count' code. If I loop through
    | it in some other way then the first access into the search results then
    | takes the nasty hit. No matter what the access is, (the count or a
    | single property on a SearchResult object). I have re-arranged the loop
    | that goes through this result set a couple of different ways and
    | whatever does the first access into the data takes the at least a .44
    | sec hit.
    |
    | Does anyone know what I am doing wrong?
    |
    | -Cam
    bruce barker, Nov 24, 2004
    #2
    1. Advertising

  3. cameron

    cameron Guest

    Tune Active Directory.... Do you have any resources/links on how to do that?

    -Cam

    bruce barker wrote:

    > actually LDAP is fast lightweight protocol for talking to a directory
    > service. this does not imply the directory service is fast. if you are
    > quering an active directory service, you may have performance problems
    > unless the AD has been tuned.
    >
    > -- bruce (sqlwork.com)
    >
    >
    >
    > "cameron" <> wrote in message
    > news:...
    > | I have always been under the impression that LDAP was optimized for
    > | speed. Fast queries, fast access, slower writes. I have a block of data
    > | in LDAP and in SQL. Exact same data. The query is fast but the first
    > | access to the result set takes longer that to do the query in SQL and
    > | process the sql results.
    > |
    > | From my trace.axd
    > | LDAP Test Starting Search 0.000112 0.000043
    > | LDAP Test Done Search 0.003821 0.003374 <--- fast query at .003 sec
    > | LDAP Test Build XML Doc 0.003906 0.000086
    > | LDAP Test For Loop 0.461937 0.458031 <-- The top of the for loop
    > |
    > |
    > | Trace.Write(Name, "Build XML Doc");
    > | for(int i=0; i<Results.Count; i++)
    > | {
    > | Trace.Write(Name, "For Loop");
    > | ....
    > |
    > | I have traced this down to the 'Results.Count' code. If I loop through
    > | it in some other way then the first access into the search results then
    > | takes the nasty hit. No matter what the access is, (the count or a
    > | single property on a SearchResult object). I have re-arranged the loop
    > | that goes through this result set a couple of different ways and
    > | whatever does the first access into the data takes the at least a .44
    > | sec hit.
    > |
    > | Does anyone know what I am doing wrong?
    > |
    > | -Cam
    >
    >
    cameron, Nov 24, 2004
    #3
  4. cameron

    bruce barker Guest

    try google, also there are training courses and books on this topic.

    -- bruce (sqlwork.com)


    "cameron" <> wrote in message
    news:%...
    | Tune Active Directory.... Do you have any resources/links on how to do
    that?
    |
    | -Cam
    |
    | bruce barker wrote:
    |
    | > actually LDAP is fast lightweight protocol for talking to a directory
    | > service. this does not imply the directory service is fast. if you are
    | > quering an active directory service, you may have performance problems
    | > unless the AD has been tuned.
    | >
    | > -- bruce (sqlwork.com)
    | >
    | >
    | >
    | > "cameron" <> wrote in message
    | > news:...
    | > | I have always been under the impression that LDAP was optimized for
    | > | speed. Fast queries, fast access, slower writes. I have a block of
    data
    | > | in LDAP and in SQL. Exact same data. The query is fast but the first
    | > | access to the result set takes longer that to do the query in SQL and
    | > | process the sql results.
    | > |
    | > | From my trace.axd
    | > | LDAP Test Starting Search 0.000112 0.000043
    | > | LDAP Test Done Search 0.003821 0.003374 <--- fast query at .003 sec
    | > | LDAP Test Build XML Doc 0.003906 0.000086
    | > | LDAP Test For Loop 0.461937 0.458031 <-- The top of the for loop
    | > |
    | > |
    | > | Trace.Write(Name, "Build XML Doc");
    | > | for(int i=0; i<Results.Count; i++)
    | > | {
    | > | Trace.Write(Name, "For Loop");
    | > | ....
    | > |
    | > | I have traced this down to the 'Results.Count' code. If I loop through
    | > | it in some other way then the first access into the search results
    then
    | > | takes the nasty hit. No matter what the access is, (the count or a
    | > | single property on a SearchResult object). I have re-arranged the
    loop
    | > | that goes through this result set a couple of different ways and
    | > | whatever does the first access into the data takes the at least a .44
    | > | sec hit.
    | > |
    | > | Does anyone know what I am doing wrong?
    | > |
    | > | -Cam
    | >
    | >
    bruce barker, Nov 24, 2004
    #4
  5. How large your tree is?
    What object you are looking for?
    What scope you are searching at?
    What search condition you used?

    The search depends on your whole AD tree, if the tree is too large, and you
    also want to search all, then it shall be slow. After the first search, the
    related informaiton is cached, then the sebsequent search should be faster.
    But if you specify small cache setting, it will also effect your subsequent
    searches.


    Best regards,
    Rhett Gong [MSFT]
    Microsoft Online Partner Support

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Please reply to newsgroups only. Thanks.
    Rhett Gong [MSFT], Nov 25, 2004
    #5
  6. cameron

    cameron Guest

    I am searching in just a branch of the tree. The entire tree is fairly
    large, (a couple million objects I would guess). I am searching for one
    of our custom objects. Scope is onelevel and the search condition is
    very, very specific.

    Since the it is a onelevel search starting a specific point with a very
    specific filter I would expect the search to be quick, which it is (<
    0.003 of a second), and the result to be small, which it is, (40
    objects), what I don't understand is why the access to the first object
    in that search result collection is so slow, (.4 of a second). The size
    of the tree, the object type and the scope of the search seem irrelevant
    at this point since the actual searching is already complete.

    I have stopped using the SearchResultCollection.Count attribute since it
    not actually an attribute, it is calculated, (by looping through the
    entire collection and couting the number of objects in the collection),
    which means if you use it in a for loop to loop through your results
    that you are actually looping through the results twice. I am also
    avoiding all calculated attributes, (cn, distinguishedName... etc).

    Subsquent searches behave exactly the same. No speed increase in
    accessing the first object.


    Rhett Gong [MSFT] wrote:
    > How large your tree is?
    > What object you are looking for?
    > What scope you are searching at?
    > What search condition you used?
    >
    > The search depends on your whole AD tree, if the tree is too large, and you
    > also want to search all, then it shall be slow. After the first search, the
    > related informaiton is cached, then the sebsequent search should be faster.
    > But if you specify small cache setting, it will also effect your subsequent
    > searches.
    >
    >
    > Best regards,
    > Rhett Gong [MSFT]
    > Microsoft Online Partner Support
    >
    > This posting is provided "AS IS" with no warranties, and confers no rights.
    > Please reply to newsgroups only. Thanks.
    >
    cameron, Nov 25, 2004
    #6
  7. Hi Cameron,
    I agree with the answer from Willy Denoyette.
    Please read his suggestion in your post of csharp queue, and we will follow
    up you there.

    Thanks,
    Rhett Gong [MSFT]
    Microsoft Online Partner Support

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Please reply to newsgroups only. Thanks.
    Rhett Gong [MSFT], Nov 26, 2004
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. cameron

    DirectorySearcher & sorting

    cameron, Jul 4, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    4,749
    Yan-Hong Huang[MSFT]
    Jul 7, 2003
  2. dave
    Replies:
    0
    Views:
    767
  3. Jay
    Replies:
    1
    Views:
    19,255
  4. =?Utf-8?B?QW5kcmV3MTI0?=

    DirectorySearcher.FindAll()

    =?Utf-8?B?QW5kcmV3MTI0?=, Jul 11, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    2,319
    =?Utf-8?B?QW5kcmV3MTI0?=
    Jul 11, 2004
  5. Roger Bavaud

    DirectorySearcher Filter Exchange Server

    Roger Bavaud, Nov 3, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    605
    =?Utf-8?B?UGF0cmljay5PLklnZQ==?=
    Nov 5, 2004
Loading...

Share This Page