OpenLDAP 2.3 has been unrivaled as the fastest directory server in the world for the past two+ years, but today that's no longer true. Now OpenLDAP 2.4 takes over as the most scalable, most reliable, highest performing directory server.
Thanks to our friends on the Samba Project and at AMD, we've been able to do some new benchmarks on an AMD quad-processor server. We tested OpenLDAP (2.4.5 and 2.4.6) on Linux as well as Microsoft's AD offerings on Windows 2003, and the results are now summarized on the Connexitor blog.
(The AD numbers aren't all in yet, we're still waiting for the directory import to finish.)
Em Sáb, 2007-11-03 às 03:30 -0700, Howard Chu escreveu:
OpenLDAP 2.3 has been unrivaled as the fastest directory server in the world for the past two+ years, but today that's no longer true. Now OpenLDAP 2.4 takes over as the most scalable, most reliable, highest performing directory server.
Thanks to our friends on the Samba Project and at AMD, we've been able to do some new benchmarks on an AMD quad-processor server. We tested OpenLDAP (2.4.5 and 2.4.6) on Linux as well as Microsoft's AD offerings on Windows 2003, and the results are now summarized on the Connexitor blog.
(The AD numbers aren't all in yet, we're still waiting for the directory import to finish.)
In the authentication and other online tests, were the ACLs on all servers the same? Or no ACLs whatsoever? I suppose this would have an impact on performance.
Andreas Hasenack wrote:
Em Sáb, 2007-11-03 às 03:30 -0700, Howard Chu escreveu:
(The AD numbers aren't all in yet, we're still waiting for the directory import to finish.)
In the authentication and other online tests, were the ACLs on all servers the same? Or no ACLs whatsoever? I suppose this would have an impact on performance.
It's not really possible to make the ACLs identical, since the servers' access control systems are very different. Nor is it meaningful to turn off all of the ACLs. As such, a minimal set of rules are used on each server, but that set is necessarily different in each implementation. I believe this is still fair, since the security implementation is an integral part of each server.
E.g., all the servers use TCP/IP, but their TCP/IP implementations are also different. That's just one of many intrinsic elements that defines the properties of a given server.
For AD and ADAM we used their default security settings. Since by default they don't allow anonymous operations, we created a "cn=bench" user for authenticating each session. Also in AD and ADAM a user needed to belong to a particular group in order to have read access to the rest of the DIT. So we also created a "cn=readers" group in OpenLDAP with our bench user as a member and set the corresponding ACLs.
Likewise, I have no idea what the default mechanism for validating a plaintext Simple Bind password is in AD/ADAM. We tested OpenLDAP with both plaintext and SSHA hashes. Computing an SHA hash is certainly more CPU intensive than just doing a simple memcmp on a plaintext password, but is it equivalent to AD's hash? Who knows? AD isn't documented well enough for anyone to say. But ultimately it doesn't matter, because you cannot change AD's configuration and choose a different mechanism. So in terms of comparing overall server behavior, sure there will be differences, but those are intrinsic to each server implementation. Those intrinsic differences are indeed the entire reason why comparative testing needs to be done in the first place...
-- -- 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/
openldap-software@openldap.org
-
Andreas Hasenack -
Howard Chu