I have been very clear that past setting up the tree, I have not done much to configure either OpenLDAP or OpenDS and that the test are based on an “out-of-the-box” install. I have no doubt that they would both perform better if I spent time tuning them, which I will. This is just the first set of testing.

One thing won’t change with testing though, and that is the ease of use of OpenDS vs OpenLDAP – you guys (OpenLDAP) I believe are more focused on high performance and use by folks who tend to use CLI tools and who have deep experience with LDAP, while I think OpenDS (and ApacheDS too) apply some of their focus on a different kind of user experience that can extend LDAP into the hands of new folks. Honestly, my opinion is that those tools do have a better user experience and are less intimidating to folks than OpenLDAP.

I do appreciate your comments and your offer to work with me on this and will contact you via e-mail.

http://blog.zrmt.com/2007/10/18/rhel5-openldap/

or http://www.symas.net/portal/index.fcgi

In the meantime, it’s well documented that you must tune various settings first. The default BerkeleyDB cache is only 256KB. The default data layout stores everything in one place but you really need to keep transaction logs on a separate spindle from the database files, etc. All of this is spelled out in the Admin Guide.

http://www.openldap.org/doc/admin24/tuning.html

I’m not telling you how I “think it should work” – I’m telling you how it *does* work, when you follow the documentation. That’s not theoretical, that’s actual.

There’s other factors that may come into play, not all of which are directly under our control. E.g., the default malloc implementation in glibc was extremely bad up until very recently.

http://highlandsun.com/hyc/malloc/

(To be honest, I haven’t benchmarked a current glibc yet to see if it’s really fixed. I’ve pretty much switched to tcmalloc for all my critical installations and haven’t looked back.)

You can email me if you want to investigate this further.

On running on Windows – I know that quite a bit of work was done on Windows, and when I got it running it ran quite well. I did choose my words carefully though – I said “SEEMED to have developers that honestly couldn’t have cared less about supporting the Windows environment”. Configure:make did not work, and it took quite a bit of time to make it work. What it looked like to me was that someone had done a lot of work to make it run on Windows, but then much of that work was stepped on and I could not compile the code without making a significant number of changes. The part that led me to believe that no one cared was that when I asked some question I was told that Windows was not supported and I would need to figure it out myself. I was basically told to go it my own, which I did. You have to admit, that was not a very positive experience.

Not too mention this particular statement in the FAQs on the site:

“Information useful in building OpenLDAP 2.X-devel (HEAD) on MS Windows NT/2000. The NT/2000 port is experimental. Other Win32 platforms have yet to experimented with. Your mileage may vary! ”

This was certainly true at the time for Win2000, which is what were were trying to compile on.

All things considered, I did get it running, and we did choose it because other than that glitch and the surliness of the team supporting we were happy with the product.

On the older version of OpenLDAP compared to the new OpenDS – you have a good point, but I don’t control what is in the CentOS repository. The rules we set up for this test were that we did not want to build the software, but wanted to get a prepackaged software. I do think that a new version would have run better, but probably not that significantly, it is only a year old … it’s not like the software is 5 years old. The comparison is 1 year old software vs. 6 month old software.

I specifically did not do any tuning at this point – I was quite clear that I was running it out of the box – packaged software configured for my org, but not tweaked in any way.

I can’t explain the slowness of the response times, that was very surprising to me as well. I am more than happy to work with others on doing some additional work in this area. I have already spoken with people from OpenDS and Apache about various aspects of these tests, and I am more than happy to talk to folks from OpenLDAP. I want to choose the best tool for our company, but also provided valuable, accurate information based on MY experience, not on how others think it should work.

In fact Symas has spent quite a bit of time and energy into checking how well OpenLDAP performs on Windows.

http://connexitor.com/blog/pivot/entry.php?id=181

(Quite well, thank you very much.) Of course, that round of testing did reveal some other opportunities for optimization, which were committed to the CVS repository 2 weeks later.

http://www.openldap.org/lists/openldap-commit/200711/msg00185.html

As for the situation Now, I’m inclined to point out that it’s unfair of you to take a crufty old CentOS release and compare it against an extremely new OpenDS release. If you’re going to use an OpenDS that was written within the past 6 months then you ought to be comparing against an OpenLDAP release from within the past 6 months; Red Hat is well known to be an extremely poor distro in terms of OpenLDAP packaging, perennially out of date, and CentOS doesn’t improve on that. But that’s rather beside the point…

A properly configured OpenLDAP will blow the doors off a properly configured OpenDS and every other directory server on the planet.

Your graphs show average operation response times on the order of 10 seconds, which I’ve never seen even with every possible debug option turned on. There’s something seriously wrong with your setup, and I’d be curious to see what the problem is.