Re: back-mdb status

[Howard Chu <hyc@symas.com>]

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

real    0m11.019s
user    0m0.000s
sys     0m11.009s

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/