Howard Chu wrote:
At this point the libmdb library code is behaving pretty well, and the back-mdb is code-complete. It is not yet passing all of make test, but it does pass the majority of tests so far. As expected, it delivers higher throughput than back-bdb/hdb under heavy load, with a smaller memory footprint, and nothing to tune. So far so good.
Summary of changes: servers/slapd/back-mdb/bind.c | 10 ++-------- servers/slapd/back-mdb/compare.c | 10 ++-------- servers/slapd/back-mdb/id2entry.c | 4 +++- servers/slapd/back-mdb/operational.c | 10 ++-------- servers/slapd/back-mdb/referral.c | 10 ++-------- servers/slapd/back-mdb/search.c | 10 ++-------- 6 files changed, 13 insertions(+), 41 deletions(-)
You'll note that for most of the commits the deletions far outweigh the insertions. I made the MDB API similar to the BDB API in most areas, so the effort of porting wasn't too great. Most of the effort was simply in deleting; fully 1/3rd of back-bdb/hdb's code was deleted to get back-mdb running. This is more of what I originally intended back-hdb to be from the beginning... Now if we just go forward with my idea to move all slapd global variables into a single structure, it would be trivial to persist all of slapd's runtime state into the mmap as well.*
Mebbe OpenLDAP 3.0 will get there - instant-on server... http://www.openldap.org/lists/openldap-devel/200410/msg00000.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/