07 August 2006 - 07:16Sun's OpenDS
Well, Sun finally open sourced a directory. Of course, it's not THE Sun directory. And the hype explanation around this one is quite transparently written by the spin doctors carefully crafted by the marketing team.
Read on for a little more opinion from the Symas team ...
Naturally, Symas applauds the goals of "to address large deployments, to provide high performance, to be highly extensible, and to be easy to deploy, manage and monitor". We might point out that OpenLDAP provably accomplishes all those ends and has done so for some time now. From the FAQs and the other comments in various places, we figure there's lots to do to finish the project.
We were amused to see "the codebase is over ten years old and its origins are from a time when performance, scalability, and feature set requirements then were very different from what we're seeing today and expect to see in the future" in a posting from Neil Wilson of Sun waxing optimistic about the new software. It goes on to say that the next release of Sun's Directory Server (6.0) will be the best yet.
The OpenLDAP Project undertook a virtual rewrite of the University of Michigan reference implementation over a period of several years (and releases). That rewrite, largely led by Howard Chu, Chief Architect of Symas, resulted in major restructuring, replacement of virtually every key performance-related algorithm, and the adoption of the ACID capable Sleepycat (Berkeley) Database. All of this means that the OpenLDAP source base is positioned very well to respond to requirements we're seeing today.
This move by Sun probably confuses a lot of people. We are repeatedly told by customers that they expect Sun to Open Source the current Directory Service product. Now, they've put an incomplete replacement product into Open Source and people are curious how deep their commitment is to the existing product. The Java rewrite was not a well-known initiative until this step was announced. That's kind of a confusing switch.
We wonder how anyone really expects a Java-based Directory to perform well when it uses dynamic, system-managed garbage collection and the system is a very heavy user of dynamic memory allocation (take a look at this report). The old performance battle between Java and C will be resurrected here. Symas looks forward to the opportunity to benchmark head-to-head with OpenDS when it gets to the point that it's a credible alternative. We don't expect that its performance will be anywhere near that of OpenLDAP for many reasons.
One can only speculate on this move. What's said up front is clearly pretty carefully crafted to avoid saying the obvious. You have to wonder why, if this was the project to do the future replacement for the existing software, they would open source it at this stage? Somehow, it smells of de-emphasis by the corporation, not commitment. And, given all the challenges the existing product has, what does the existence of OpenDS say about the medium to long term future about the Directory Server so many are struggling with. The whole move smacks of deceleration.
Meanwhile, we are days away from the biggest replacement of Sun's directories with Symas's Connexitor™ Directory Services (CDS) distribution of OpenLDAP. More on that soon but we're really over the hump on that one and it's into the fabric of a major fortune 100 company. That should get some attention.
... Marty
two comments:
Having re-factored OpenLDAP’s slapd at least twice in the past seven years, I can say that stepwise refinement isn’t such a bad approach. Our benchmarks show that our work has been successful, at least, without resorting to a throw-out-the-baby-with-the-bathwater ground up rewrite.
The ability to do dynamic profiling sounds nice, but you’re paying a continual, heavy price in overhead to support features that are only meant to be used occasionally. On Linux we can use oprofile as needed, without paying any extra overhead in the application code itself when it’s turned off.
You might as well write the service in Pascal and run it on the UCSD p-system. Once you make the decision to use an interpreted language in a virtual machine, you have implicitly decided that performance is not a goal because it is most certainly out of your hands as an application developer.
Our experiences with SLAMD already bear this out – it takes 12 SLAMD java clients to generate the same amount of load as a single C client for the Authentication workload. So from the get-go your Java-based server is going to be more than an order of magnitude slower than a C-based server. How anyone can start there and aim to create the world’s best/fastest server is utterly incomprehensible.
http://www.saleveling.com http://www.power-leveling-game.com
No trackbacks: