[Date Prev][Date Next]
Re: back-mdb status
Howard Chu wrote:
A couple new results for back-mdb as of today.
first second slapd size
back-hdb, 10K cache 3m6.906s 1m39.835s 7.3GB
back-hdb, 5M cache 3m12.596s 0m10.984s 46.8GB
back-mdb 0m19.420s 0m16.625s 7.0GB
back-mdb 0m15.041s 0m12.356s 7.8GB
Next, the time to execute multiple instances of this search was measured,
using 2, 4, 8, and 16 ldapsearch instances running concurrently.
average result time
2 4 8 16
back-hdb, 5M 0m14.147s 0m17.384s 0m45.665s 17m15.114s
back-mdb 0m16.701s 0m16.688s 0m16.621 0m16.955s
back-mdb 0m12.009s 0m11.978s 0m12.048s 0m12.506s
So back-mdb is faster than back-hdb whenever there's more than one query
running. Also with result times of 0m11.699s measured, back-mdb is within 7%
of back-hdb's speed even in the single-query case, where hdb has zero lock
contention and all it has to do is dump cached entries from RAM (i.e.,
back-hdb is doing practically zero work at all).
For comparison, the time dd the raw DB file to /dev/null:
hyc@ada:~$ time dd if=/mnt/hyc/data/ldap/mdb/db/data.mdb of=/dev/null bs=1024k
18643+1 records in
18643+1 records out
19548712960 bytes (20 GB) copied, 11.0087 s, 1.8 GB/s
So effectively, back-mdb with all of slapd wrapped around it only adds 10%
overhead compared to just copying the raw data as fast as possible.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/