Subject: updated: slapd performance test results To: ldap@umich.edu Cc: hodges From: Jeff.Hodges@stanford.edu Date: Wed, 10 Jul 96 12:04:36 -0700 (this copy updated 16-Jul-97) I performed a "let's max slapd out as much as possible" test yesterday, and have added the info to the results below. Also, I'd left out that the dbase technology we're presently using beneath slapd is gdbm-1.7.3. Bottom line: I got slapd on a 64mb Sparc 2/Solaris 2.4 to run at a sustained rate of about 1,434,240 "bind/search/unbind" (aka "heavyweight) connections per 24 hr period (i.e. about 16.6 hvywhtConn/sec). It was servicing 44 concurrent clients, each querying the directory as quickly as possible (given what was going on on them at the time). Jeff -------------------------------------------------------------------------- Slapd Testing Results Jeff.Hodges@Stanford.edu Last updated: 16-Jul-97 Contents: Basic server-side test results Test setup slapd server config... Clients config... Directory structure... Client-side test results Client-side perl script -------------------------------------------------------------------------- Basic server-side test 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 22 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 rate was sufficient to, in the vast majority of connections, service these clients within the range of their TCP timeouts. I got << 100 timeouts among the 4.5M queries. It is interesting to note that the timeouts were exclusively on "slow" (e.g. other sparc2) machines and/or heavily-loaded ones. I obtained no timeouts on "fast" machines (e.g. Dec Alpha 400/233). 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..44 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 test results: I kept client-side logs on a few of the client machines during the above test. These logs provide query timing information, system load, # of users, and note timeout occurances. I processed these logs and obtained the histograms shown below. During the period the test was running, SlowClient (a fairly-heavily loaded Sparc2) had... 2..13 users load varied roughly between 3..5 To me, the short answer that the histograms below provide is that a simple directory lookup (note that it is a "heavyweight" query in that it is a bind/query/unbind sequence) will typically cost a direct user (i.e. a human or a program) 1 sec or less to accomplish in around 90% of the cases on a machine with operating characteristics similar to SlowClient. 8% of the time the query might take 1..10 secs. 2% of the time it will take longer. It will very seldom timeout. And the numbers probably only get better (in general). Take FastClient (see report below). It sez that 99% of the time the query will take 1 sec or less. --------------------------------------- SlowClient: Sparc 20, Solaris 2.4, 64mb, multi-user, 2..13 users during test period, load varied roughly between 3..5 *** Timing Log Analysis *** Analysis of log performed on: Fri Jun 14 12:54:32 1996 First logged timestamp: 13-Jun-1996 08:14:23 Last logged timestamp: 14-Jun-1996 12:53:22 secs # of occurances % of total queries 0 23706 29 1 48224 59 2 1897 2 3 372 0 4 56 0 5 1428 1 6 3336 4 7 1337 1 8 109 0 9 19 0 10 109 0 11 200 0 12 86 0 13 3 0 14 2 0 15 1 0 16 3 0 17 1 0 18 136 0 19 116 0 20 13 0 21 2 0 23 8 0 24 11 0 42 7 0 43 11 0 Total number of queries: 81193 Average response time, to the user, for a query was: 1.40 seconds. [note that this *simple average* is highly skewed by a few of the queries, approx 2%, taking longer than 10 sec.] Number of queries that timed out for whatever reason: 1 --------------------------------------- FastClient: DEC Alpha 400/233, 64mb, OSF/1 3.2a, single user, load average was consistently less than 1.0 during the test. *** Timing Log Analysis *** Analysis of log performed on: Fri Jun 14 14:51:06 1996 First logged timestamp: 12-Jun-1996 11:12:59 Last logged timestamp: 14-Jun-1996 14:50:55 secs # of occurances % of total queries 0 84067 43 1 104604 54 2 2764 1 3 25 0 4 405 0 5 268 0 6 49 0 7 10 0 8 3 0 9 8 0 10 120 0 11 56 0 15 1 0 16 1 0 22 8 0 23 2 0 25 1 0 27 1 0 Total number of queries: 192393 Average response time, to the user, for a query was: 0.82 seconds. Number of queries that timed out for whatever reason: 0 -------------------------------------------------------------------------- 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=". # 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 = ) { chop $name; open(LDAP, "/usr/pubsw/bin/ldapsearch -h 'cn=$name' dn |"); while($result = ) { 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