469,645 Members | 1,150 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,645 developers. It's quick & easy.

DirectorySearcher first access speed

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
Nov 16 '05 #1
4 7773
Please post your code, and give us an idea about the size of the directory.
Some details about your configuration would help also.

Willy.

"cameron" <ca****************@appdepot.com> wrote in message
news:u8*************@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

Nov 16 '05 #2
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.

Nov 16 '05 #3
The Code, I have tried to simplify it as much as possible:

....

Trace.Write(Name, "Starting Search");

DirectoryEntry DE = new DirectoryEntry( "LDAP://" + DN,
NTUsername, Password);
DirectorySearcher Searcher = new DirectorySearcher(DE);
Searcher.Filter = ValidDateFilter();
Searcher.PropertiesToLoad.Add("ADsPath");
Searcher.SearchScope = SearchScope.OneLevel;
SearchResultCollection Results = Searcher.FindAll();

Trace.Write(Name, "Done Search");

IEnumerator EnumResult = Results.GetEnumerator();
while(EnumResult.MoveNext())
{
SearchResult oResult = (SearchResult)EnumResult.Current;
Trace.Write(Name, oResult.Properties["ADsPath"][0].ToString());
}

Trace.Write(Name, "Done Loop");

....

// the filter
protected virtual string ValidDateFilter()
{
StringBuilder SearchFilter = new StringBuilder();
DateTime oBaseDate = new DateTime();
oBaseDate = DateTime.Now;

SearchFilter.Append("(&(appdepot-adxDocType=IDXFund.1)");
SearchFilter.Append("(!(&(appdepot-adxExpirationDate<=");
SearchFilter.Append(oBaseDate.ToUniversalTime().To String("yyMMddHHmmss")+"Z)");
SearchFilter.Append("(appdepot-adxExpirationDate=*)))");
SearchFilter.Append("(|(appdepot-adxReleaseDate<=");
SearchFilter.Append(oBaseDate.ToUniversalTime().To String("yyMMddHHmmss")+"Z)");
SearchFilter.Append("(!(appdepot-adxReleaseDate=*)))");
SearchFilter.Append("(|(appdepot-adxState=Approved)");
SearchFilter.Append("(!(appdepot-adxState=*)))");
SearchFilter.Append(")");

return SearchFilter.ToString();

}//ValidDateFilter

The directory has a at least a million objects in it, (I have never seen
a way to get the exact size from the AD so I am just guessing). As for
the configuration you will have to be more specific, I am a programmer
and have little to nothing to do with the AD configuration, but I can
ask if I know what you want me to ask.

-Cam

Willy Denoyette [MVP] wrote:
Please post your code, and give us an idea about the size of the directory.
Some details about your configuration would help also.

Willy.

"cameron" <ca****************@appdepot.com> wrote in message
news:u8*************@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


Nov 16 '05 #4
Seems like you have some misconception on how LDAP really works.
Whenever you execute - Searcher.FindAll(); the LDAP server executes the
query applying the Filter criteria defined, and stores the resultset in an
internal buffer (at the server), the size of this resultset is limited at
max. 1000 objects.
In your case this query takes :
LDAP Test Done Search 0.003821 0.003374 <--- fast query at .003 sec
Now you start enumerating the resultset, executing something like :
[foreach(SearchResult sc in Results ); or Results.Count; ], at this point
the ADSI client starts to pull the buffered resultset from the server to the
client (and cache it at the client per default - see
DirectorySearcher.CacheResults), and does this in chunks of
DirectorySearcher.PageSize.
Note that the default for PageSize is 0, which means - transfer the whole
resultset (max. 1000 objects).
This is the 0.45 sec. hit you are taking, this transfer time highly depends
on the number of objects in the server buffer and the transport medium (see
1).
If you know that the resultset will be large and you don't want to take the
hit, You could try to set the PageSize value (let say to 10). This will
lower the hit taken, however, this hit will be taken for every 'pagesize'
transfered.

Hope this helps.
Willy.

[1] this is what I meant with configuration. If you are running the client
on a workstation over a network, you have to consider things like the
network speed/topology, authentication scheme, server resources (CPU's,
speed, memory), size of the AD, disk IO subsystem, number of AD users, type
of queries they run, etc.....
So I can't realy comment on the .45 seconds hit if I don't know the size of
the resultset, and the 'distance' between client and server.
If the resultset is 1000 objects and the connection is "same server" the a
..45 sec's hit looks quite normal.


"cameron" <ca****************@appdepot.com> wrote in message
news:ea*************@TK2MSFTNGP11.phx.gbl...
The Code, I have tried to simplify it as much as possible:

...

Trace.Write(Name, "Starting Search");

DirectoryEntry DE = new DirectoryEntry( "LDAP://" + DN,
NTUsername, Password);
DirectorySearcher Searcher = new DirectorySearcher(DE);
Searcher.Filter = ValidDateFilter();
Searcher.PropertiesToLoad.Add("ADsPath");
Searcher.SearchScope = SearchScope.OneLevel;
SearchResultCollection Results = Searcher.FindAll();

Trace.Write(Name, "Done Search");

IEnumerator EnumResult = Results.GetEnumerator();
while(EnumResult.MoveNext())
{
SearchResult oResult = (SearchResult)EnumResult.Current;
Trace.Write(Name, oResult.Properties["ADsPath"][0].ToString());
}

Trace.Write(Name, "Done Loop");

...

// the filter
protected virtual string ValidDateFilter()
{
StringBuilder SearchFilter = new StringBuilder();
DateTime oBaseDate = new DateTime();
oBaseDate = DateTime.Now;

SearchFilter.Append("(&(appdepot-adxDocType=IDXFund.1)");
SearchFilter.Append("(!(&(appdepot-adxExpirationDate<=");
SearchFilter.Append(oBaseDate.ToUniversalTime().To String("yyMMddHHmmss")+"Z)");
SearchFilter.Append("(appdepot-adxExpirationDate=*)))");
SearchFilter.Append("(|(appdepot-adxReleaseDate<=");
SearchFilter.Append(oBaseDate.ToUniversalTime().To String("yyMMddHHmmss")+"Z)");
SearchFilter.Append("(!(appdepot-adxReleaseDate=*)))");
SearchFilter.Append("(|(appdepot-adxState=Approved)");
SearchFilter.Append("(!(appdepot-adxState=*)))");
SearchFilter.Append(")");

return SearchFilter.ToString();

}//ValidDateFilter

The directory has a at least a million objects in it, (I have never seen a
way to get the exact size from the AD so I am just guessing). As for the
configuration you will have to be more specific, I am a programmer and
have little to nothing to do with the AD configuration, but I can ask if I
know what you want me to ask.

-Cam

Nov 16 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Jayant Sane | last post: by
3 posts views Thread by cameron | last post: by
2 posts views Thread by Jason S | last post: by
1 post views Thread by Jay | last post: by
6 posts views Thread by cameron | last post: by
1 post views Thread by =?Utf-8?B?TGFtaXM=?= | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.