"The LDAP Guys."

Symas Benchmarking - Authorization Marks

The folk-story that OpenLDAP is slow has dogged the software for years. There haven't been any in-depth benchmarks published in some time and Symas has contributed numerous significant performance enhancements. Recently, an opportunity arose to make a comparison.

Neil Wilson, an employee of Sun Microsystems and author of the slamd benchmarking software recently published a set of benchmarks of the Sun Java System Directory Server. Symas was interested to see how CDS would perform under similar conditions. We set up a set of benchmarks using the same job templates for slamd.

Hardware involved

• Sun Fire T2000 with 8 core Sparcv9 1.0GHz CPU, 16GB DDR2 RAM, and 2x 73GB 10K RPM SAS disk. This system is identical to the system used by Sun except it has one half the memory.
• Sun Fire X4100 with 2 single-core AMD Opteron 2.8GHz Model 254 CPU, 8GB PC3200 DDR-400 RAM, and 2x 73GB 10K RPM SAS disk.
• HP Integrity rx2620-2 with dual Itanium-2 1.6GHz CPU, 16GB PC2100 DDR-266A RAM, and 2x 73GB 15K RPM Ultra320 SCSI disk.

Operating Systems Involved

• Solaris 10 on the Sun Fire T2000 and Sun Fire X4100 systems.
• Debian Sarge x86_64 (2.6 kernel) on the Sun Fire X4100 system.
• Red Hat Enterprise Linux AS release 3 (2.4 kernel) on the HP Integrity rx2620-2 system.
• Red Hat Enterprise Linux AS release 4 (2.6 kernel) on the HP Integrity rx2620-2 system (testing in progress, results not yet available).

Data and Configuration

• For this benchmark, the default slamd ldif template was modified slightly to be usable with CDS.
• For the nominal resource usage benchmark, entry cache was completely filled and an equivalent IDL cache was set.
• For the resource intensive benchmark, an IDL cache value equal to the number of entries was used, and a significantly smaller entry cache.
• A tarball of the slapd.conf, DB_CONFIG configurations, and the example.template file used can be downloaded.

Disk Layout and Swap

• For these systems, each database was stored on the secondary drive, with the logfile directory and swap located on the primary drive.
• A large swap partition was necessary for the resource intensive benchmark. Total Memory + 8GB was the rule of thumb.

Key differences to the Sun benchmark

• A maximum of 16 GB available to on any of the systems. Since the 10 million entry test in the Sun case was a test of how the server performed while under resource restraints due to the size of the database, a proportional number was used in the Symas benchmark.
• Solaris 10 x86_64 was used with the AMD systems rather than Nevada as used on the Dell in the Sun test.
• Different sets of hardware were used to generate the SLAMD load. However, the back-null database was used on a secondary benchmark to ensure that the load generators were not performance bottlenecks.
• Access logging was disabled.
• A 64 bit version of CDS was used on all platforms.
• The example.template file did not have all of the attributes used by the Sun benchmark. However, the authentications benchmark does not transfer entries across the wire, so the only effect is on resource usage in the cache.

Results

Sun Java System Directory Server vs CDS on T2000

CDS was 19% faster than JEDS at 250k entries and 32% faster at 1 million. It was 56% faster at resource constrained levels but, as the number of entries was adjusted to match memory size, this may not be precisely accurate.

T2000 vs HP rx2620-2 (RHEL AS 3)

CDS was 32% faster on the HP Integrity than on the T2000 for the 250K entries run and 26% faster for the 1 million entry run. Something about the older kernel (2.4) and its libraries appear to have aggravated memory usage and the Integrity was 44% slower than the T2000 under Solaris for the resource-constrained test.