[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: thread pools, performance

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/