Hi Howard. On the slide "The Road Ahead..", you mention a scale-out need
to "allow multi-terabyte DBs to be served without requiring a single
giant server". Can you discuss what you mean a bit farther, especially
in comparison to a distributed directory? I guess I don't see the
specific advantage.. The only thing that really caught my attention on
this slide was "cluster-friendly optimizations", which makes sense, but
how powerful is this need really?
--
Puryear Information Technology, LLC
Baton Rouge, LA * 225-706-8414
http://www.puryear-it.com
Author:
"Best Practices for Managing Linux and UNIX Servers"
"Spam Fighting and Email Security in the 21st Century"
Download your free copies:
http://www.puryear-it.com/publications.htm
Howard Chu wrote:
For anyone curious, the slides from my presentation at the SambaXP
conference last week are now up on my web site.
http://highlandsun.com/hyc/SambaXP.pdf
Much of the material on malloc benchmarking was already presented at
SCALE5x earlier this year. New material in these slides include
benchmark results for OpenLDAP 2.3.34 vs FedoraDS 1.0.4, OpenDS 0.1-34,
and ApacheDS 1.0.1 on Linux 2.6. The machine used for these tests is the
same SunFire X4100 used in these tests last year
http://www.symas.com/benchmark-auth.shtml
We didn't test Microsoft ActiveDirectory because we don't have a 64 bit
build of it available, nor do we have a 64 bit Windows system available.
I suppose we can run those tests and publish those results sometime down
the road. If anybody is interested in helping to run more tests along
these lines, feel free to contact me.
This round of benchmarking was quite educational. We discovered a memory
leak in FedoraDS (and reported that to their maintainers, of course).
Analyzing the results also shows that while FDS' entry cache is
reasonably effective, they have a performance bottleneck in their
frontend, most likely in connection management. I didn't profile it to
get a closer look, though I'm sure a profiler would make the culprit
obvious.
Also FDS is too memory hungry, which causes their server to run out of
memory much sooner than OpenLDAP (running on the identical machine, with
identical cache memory settings, indices, workload, etc...) so their
performance drops off quite sharply as database sizes increase and
memory becomes constrained. (This is something different from the malloc
degradation I was observing in OpenLDAP before, although FDS appears to
be affected by that as well.)
We also observed that Sun/Fedora's documentation and advice on
performance tuning for their servers is wrong, and we can obtain better
performance by ignoring their recommendations. Even though Sun, Fedora,
and OpenLDAP all use BerkeleyDB, it's obvious that they don't use it as
effectively as we do.
Given the extremely young age of the OpenDS code base I'd say they've
done a really good job thus far, even managing to beat FDS in one test.
But I'd also say they've gotten as good as they can possibly get with a
pure Java solution; indeed their future plans for entry caching require
support outside the JVM (e.g. using a tmpfs cache). Since they're still
at best 3x slower than OpenLDAP, it's unlikely they will ever achieve
their stated goal of delivering high performance with a Java code base.
OpenLDAP has taken a lot of flack over the years for being slow or old
technology. Most of that was well-deserved up to about mid-2000, but it
hasn't been true since.
OpenLDAP is the fastest, most scalable, most reliable directory software
in the world. That's not marketing hype; we can prove every point. AMD
and Intel make a big deal about piddly 20% differences between their
products. We are over 300% faster than the next closest offering. Other
projects and vendors talk about how superior they are (or hope to be)
but it's pretty clear that they're not in the ballpark. They're not even
in the same league. I don't wish ill to any of these folks, but
personally I'm sick and tired of the unfounded claims. A lot of people
are spinning directory stories these days. With OpenLDAP there's no need
for spin, we're the best, and that's the truth.
---
You are currently subscribed to ldap@umich.edu as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
