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