Bottom line: it's pretty fast, i.e. in about the same order of magnitude as
the DNS for exact match searches.
Jeff
--------------------------------------------------------------------------
Contents:
Basic results
Test setup
slapd server config...
Clients config...
Directory structure...
Client-side perl script
--------------------------------------------------------------------------
Basic results:
sustained rate of "heavy weight" query responses generated by
slapd: 12..15/sec
"heavy weight" queries are composed of...
bind
search
unbind
...protocol operations. Each "bind/search/unbind" sequence comprised one
query (and "connection"). Each search was for a known exact match. Search
space is described below in "Test setup". A sustained rate of 12 queries/sec
translates to answering 1,036,800 queries per 24 hr period.
Total high-water mark of queries handled by the
test server w/o failure: 4,692,130
(it never failed, btw. We had to take the server down due to moving our
machine room layout around, else I would've left it all running for several
more days)
Note that the "sustained rate" climbed to the high end of the range as I
added more clients, and fell as number of clients decreased. I did not
ascertain what the ultimate max sustained rate was that this particular
server setup could generate, mostly due to laziness on my part in terms of
logging onto yet more clients and getting them going. Tho, this would be
a very interesting test, especially considering the "dynamic directory
service extensions" internet draft (and do same sort of test on "modifies").
--------------------------------------------------------------------------
Test setup:
slapd server config...
slapd 3.3 running on a Sparcstation 2, 64 mb, 1 gig run-of-the-mill disk,
Solaris 2.4.
slapd compiled with SunPro compiler, no optimization, but w/ debugging info
(-g)
slapd was run via the SunPro debugger, with memory access & leak checking OFF.
Slapd and the debugger were the only active processes of note on the machine.
NOTE: slapd had the concurrency patches applies (the same ones I posted to
ldap@umich.edu a couple weeks ago)
Clients config...
Clients varied from a DEC Alpha (64mb, Digital Unix 3.2), to a handfull of
Sparcstation 20's (Solaris 2.4).
Clients utilized the "ldapsearch" tool (part of the umich ldap release). It
had been compiled with the gnu c compiler with -O2.
The search space was 20,797 unique names. Each client had access to a flat
ascii list of all the names in the search space. Each client iterated through
the entire list over and over, querying the directory for each name.
There were between 10..18 concurrent clients at any particular time. Each
client was querying as fast as it could given load imposed by other processes
on the client machine (some were heavily loaded with users, a few had
effectively no interactive users and querying slapd was all they were doing)
and network delays in contacting the directory server (some clients were on
fairly busy nets, others on lightly-loaded nets).
This client-side was driven by a simple perl script running on each client.
(see below).
Directory structure...
The directory structure being queried was...
c=US
|
o=Stanford University
|
ou=People
|
<~21K individual entries of objectclass=person>
The actual ldap query utilized in the test is expressed in the perl script
shown below.
--------------------------------------------------------------------------
Client-side perl script:
#!/usr/local/bin/perl
#
# QueryForNames.pl
#
# a quick hack. takes a list of names on STDIN, and queries
# the directory via ldapsearch for each name. The filter is "cn=<name>".
# The DN of each entry is printed to stdout, and the query return time
# is noted.
#
# Example usage:
#
# > cat list.of.names | QueryForNames.pl > query.log &; tail -f query.log
#
while($name = <STDIN>) {
chop $name;
open(LDAP, "/usr/pubsw/bin/ldapsearch -h directrix 'cn=$name' dn |");
while($result = <LDAP>) {
chop $result;
($result,$rest) = split(/,/,$result); # extract just the CN
$whenItIs = localtime;
print "$whenItIs; $result\n";
}
close(LDAP);
}
# end of QueryForNames.pl