Re: thread pools, performance

[Howard Chu <hyc@symas.com>]

Howard Chu wrote:
> We'll remove AD and test ADAM next. At least, running as a normal user
> process, we should be able to tweak its processor affinity so we can plot how
> it scales with number of cores. Later we'll build a 64 bit OpenLDAP on Windows
> and see how it fares. My experience with 32 bit Windows has been that slapd
> runs about as fast on Windows as it does on Linux. But with the silly limits
> that Windows places on how many sockets a process can have open, (64 IIRC) you
> really can't subject it to as heavy a load in production use.

Ultimately after several more repeated runs, AD peaked at 4800 auths/sec (a 
bit faster than the 4400 we saw before, apparently it took a while for their 
caches to get fully primed). We then removed AD and installed ADAM. The import 
went a bit faster this time, thankfully:

time ldifde.exe -i -h -f examp3.ldif -s localhost -q 8
152.62u 99.32s 27:33.84 15.2%

Using 8 threads, 27-1/2 minutes. The peak authentication rate we got was just 
under 5500 auths/sec using 52 client threads. At that load a single auth took 
an average of 9.5 milliseconds, up from 1.5ms at 4 client threads. (slapd's 
average latency is only 0.5ms at 8 clients, 2.2ms at 52 clients.)

It'll be even more fun when we come back and run the tests on a 5 million 
entry DB. It's pretty clear from looking at their memory usage that they won't 
be able to cache all of that in the 16GB of RAM on this box, while OpenLDAP 
will. As such, their throughput rate will just reflect the speed of our disks, 
while slapd will still be running at full RAM speed.

> At this point I'd have a few choice things to say about Microsoft in general
> and AD in particular, but I think the numbers speak for themselves.
--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP     http://www.openldap.org/project/