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/