Date: Tue, 17 Jul 2007 11:35:26 +1000
> From: Norman Gaywood <ngaywood@xxxxxxxxxx>
> Norman Gaywood wrote:
> >perform under load? I was always under the impression that OpenLDAP
> >was the fastest and most scalable LDAP server around. For example:
> >
> >http://www.symas.com/benchmark-auth.shtml
> >
> >I recall reading another benchmark somewhere comparing it with FDS but
> >can't find it at the moment.
>
> That looks to be a read-only test. What happens when you throw some
> updates at it? And are there any benchmarks for FDS running in
> multi-master mode with update activity?
Yes it was a read-only test. But then that's the main application of
LDAP servers. Are there applications that require high LDAP write
performance?
I found the other benchmark paper here:
http://highlandsun.com/hyc/SambaXP.pdf
It includes figures for FDS. A summary can be found here:
http://www.mail-archive.com/ldap@xxxxxxxxx/msg01151.html
According to that paper, OpenLDAP pretty much blows away everyone else
in performance and scalability. Nothing else is even close.
Of course it is a benchmark. I'm sure someone will find some flaws :-)
Since everything in the code and benchmark tool set are freely available, you
can easily conduct tests on your own using your actual data. That's the best
way to get relevant results. But I'll note that on an earlier benchmark we
conducted, with a >150 million entry database at over 1 terabyte on disk,
OpenLDAP 2.3.21 was able to sustain over 4800 modifies per second concurrently
with 16000 reads per second, and full delta-syncrepl replication. (Without
writes, we were hitting 28000 reads per second, so there is definitely a
noticable cost for writes.) Granted this was a large server with 480GB of RAM
and multiple strings of RAID storage, so I/O throughput wasn't a really huge
problem. I.e., our write rate at 150M entries (4800/sec) is still higher than
anyone else's fastest read rate at 10M entries, and their performance only gets
worse if you can even stand how long it takes to load a bigger DB.
At the time we ran this test (over a year ago now) we used an SGI Altix for the
server, since Itanium systems were pretty much the only hardware that supported
a single system image with so much RAM. Today I think you could outfit a Sun
Ultrasparc with the equivalent amount of RAM. It would be interesting to rerun
this test to see how Sparc performs against Itanium.
Date: Mon, 16 Jul 2007 20:24:51 -0600
From: David Boreham <david_list@xxxxxxxxxxx>
Norman Gaywood wrote:
> Yes it was a read-only test. But then that's the main application of
> LDAP servers. Are there applications that require high LDAP write
> performance?
>
It's pretty easy to achieve performance in excess of most applications'
requirements for reads, but write performance it typically much lower
(due to the need to maintain the WAL with many indices, usually).
Replication makes the situation worse because the replication changelog
also has to be written, reducing the available I/O resources for primary
database writes. So in any given real-world application, it's often the
write capacity that determines overall system capacity.
Yes, eventually hardware becomes the limiting factor (disk throughput in this
case) but most software in the world today is written so inefficiently that
you'll never see the true hardware limits. That tends to come from people
writing code with the mindset "it's OK to use inefficient algorithms, CPUs will
always get faster." Of course, we see that CPUs have now stopped getting
faster, at least in the single-threaded sense, and the real cost of that
inefficiency (in raw electricity as well as simple hardware provisioning cost)
is hitting home. We've spent a lot of effort trimming the fat from OpenLDAP,
deleting most of the original junk code and rewriting it extensively. As a
result, you rarely see anything but actual hardware limits in its performance,
and a single OpenLDAP installation can often support the load of 3-10 times as
many other products on identical hardware. It pays to sweat the small stuff.
--
-- 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/
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
