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

Re: commit: ldap/servers/slapd connection.c daemon.c proto-slap.h syncrepl.c

Howard Chu wrote:
Howard Chu wrote: 
For reference, the peak throughput with back-null on the previous code was
only 7,800 auths/sec (with 8 client threads). With this patch it's 11,140
auths/sec. In both cases the throughput declines as more client threads are
used. (Compare to 35,553 auths/sec for the same machine running Linux, and no
drop in throughput all the way up to hundreds/thousands of connections.)

Peak throughput on the new code with back-hdb is 7,972 auths/sec (with 12
client threads).

Ah, read the preliminary result, oops. Final rate was 8,030 auths/sec.

Re-running on Linux with a non-optimized build, peaked at 40,101 auths/sec. (I guess HEAD has sped up a bit more in the past week or so...)

I forgot to note that this is using an experimental build of gcc 4.3.0
(because earlier versions don't really support the Win64 ABI) and all
optimization is turned off (due to some nasty bugs that make gcc 4.3.0's
optimizer unusable). We're tracking the bug on the mingw-w64 mailing list;
hopefully we'll have a fix soon.

This is also using BerkeleyDB 4.6.21. The 1M entry DB loads in about 8 minutes
here (vs 3 minutes on Linux) and I doubt that the optimizer is going to make
up a significant chunk of that difference. I.e., there are multiple aspects of
this OS (Windows Server 2003 SP2 Enterprise Edition x86_64) that are much
slower than Linux - not just the connection handling or disk I/O, but also
mutexes, thread scheduling, etc.

E.g., this search command against the Linux OpenLDAP build
time ./ldapsearch -x -H ldap://sihu -D dc=example,dc=com -w "secret" -LLL -b
ou=people,dc=example,dc=com -E pr=1000/noprompt 1.1 > dn1

real    0m17.766s
user    0m5.337s
sys     0m7.831s

Got this result against Windows OpenLDAP
time ./ldapsearch -x -H ldap://sihu:9000 -D dc=example,dc=com -w "secret" -LLL
-b ou=people,dc=example,dc=com -E pr=1000/noprompt 1.1 > dn1

real    0m36.553s
user    0m5.612s
sys     0m4.541s

This is with the DB fully cached, so there's no disk I/O, and the number of
network roundtrips is identical in both cases. (I guess I should measure that
again on Linux without the optimizer, to make the numbers more fair.)

With the non-optimized Linux build I got
time ./ldapsearch -x -H ldap://sihu -D dc=example,dc=com -w "secret" -LLL -b ou=people,dc=example,dc=com -E pr=1000/noprompt 1.1 > dn1

real    0m24.424s
user    0m5.366s
sys     0m4.230s

So I guess that the gcc optimizer could potentially make up to a 30% difference here.
--
-- 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/