DirectorySearcher first access speed

[cameron]

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]

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" <ca****************@appdepot.com> wrote in message
news:uL**************@TK2MSFTNGP12.phx.gbl...
| 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]

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" <ca****************@appdepot.com> wrote in message
news:uL**************@TK2MSFTNGP12.phx.gbl...
| 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]

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

-- bruce (sqlwork.com)
"cameron" <ca****************@appdepot.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
| 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" <ca****************@appdepot.com> wrote in message
| > news:uL**************@TK2MSFTNGP12.phx.gbl...
| > | 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
| >
| >

[Rhett Gong [MSFT]]

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]

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.

[Rhett Gong [MSFT]]

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.