Bottom line: I got slapd on a 64mb Sparc 2 to run at a sustained rate of about
1,434,240 "bind/search/unbind" connections per 24 hr period (i.e. about 16.6
conn/sec). It was servicing 42 concurrent clients, each querying the directory
as quickly as possible (given what was going on on them at the time).
I'm going to try a simple "let's see how many (and quickly) simple modifies
slapd will handle" test next.
Jeff
--------------------------------------------------------------------------
Slapd Testing Results Jeff.Hodges@Stanford.edu
Last updated: 10-Jul-96
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..16.6/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. 16.6/sec
translates to about 1,434,240/24hr.
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.
The "max sustained rate" that this particular slapd server setup can
generate seems to be somewhat less than 17 connections/sec (for this
particular style of simple unauthenticated bind and simple exact-match
search for a known name, and number of clients I was able to rustle up).
With about 20 clients, the server was handling connections at the rate
of 16.3/sec. I added 22 more clients for a total of 44 and got a rate of
16.6/sec. I ran out of "easily obtained" clients at that point and so
didn't add any more.
Note that this is a "search" test. Doing a similar test where each entry
is modified would be very interesting, especially considering the "dynamic
directory service extensions" internet draft.
--------------------------------------------------------------------------
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's default base DN is "o=Stanford University, c=US".
slapd utilized gdbm-1.7.3 as the underlying database technology. gdbm was
compiled with the SunPro C compiler with "-O".
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 fair pile (39
in total) 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 <host> '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
----------------------------------------------------------------------------
End of Slapd Testing Results