[Fedora-directory-users] Performance

Howard Chu hyc at symas.com
Wed Jul 18 09:31:38 UTC 2007


> Date: Tue, 17 Jul 2007 11:35:26 +1000 
 > From: Norman Gaywood <ngaywood at une.edu.au>

>> > 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@umich.edu/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 at boreham.org>

> 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/




More information about the 389-users mailing list