Re: Questions...

["Jong" <jongchoi@OpenLDAP.org>]

> Load times for 1 million entries with "index objectclass,cn eq", and
> execution times for test008 on these databases:

test008 ran on top of the 1 million entry directory or with tests/data/test.ldif ?

> 2.0 ldbm
> 611.460u 106.700s 13:36.75 87.9%        0+0k 0+0io 24570pf+0w
> real    8m20.289s
>
> 2.1 ldbm
> 577.350u 111.690s 13:33.08 84.7%        0+0k 0+0io 24597pf+0w
> real    8m54.929s
>
> 2.2 ldbm
> 615.970u 113.240s 14:09.51 85.8%        0+0k 0+0io 24636pf+0w
> real    8m59.085s
>
> 2.1 bdb
> 1305.960u 25.130s 25:38.20 86.5%        0+0k 0+0io 193749pf+0w
> real    0m23.964s
>
> 2.2 bdb
> 1350.630u 28.200s 26:37.10 86.3%        0+0k 0+0io 204497pf+0w
> real    0m10.335s
>
> 2.2 hdb
> 1107.680u 22.890s 21:57.24 85.8%        0+0k 0+0io 185340pf+0w
> real    0m9.704s
>
> The BDB/HDB tests were timed with transaction logging turned off.
>
> To recap the test008 scenario - 5 clients performing 1000 reads of a single
> entry, 5 clients performing 500 searches for a single entry, 4 clients
> adding/deleting an entry (50 times) and 4 clients executing modrdn on an
> entry (50 times). The load times for BDB/HDB can be further improved by using
> more memory, but my test machine has only 768MB, and 384MB seemed like a
> reasonable limit in this situation.

besides memory, what is the spec for other things ? CPU ?

> Note that the fastest ldbm run time (8m20s) is over 200 times slower than the
> slowest bdb run time (0m24s), and back-hdb is about 500 times faster than the
> fastest ldbm.

I've just tried to run test008 with my box (P4-2.4G) - with the test ldif file
(tests/data/test.ldif).
Both bdb and ldbm finished between 30 and 40 seconds...
My test uses the default test setup - uses the default slapd.1.conf file generated by the
test script.

The difference between ldbm and bdb became significant when indexing came into the
picture.
So this may be a sign that we should improve the bdb indexing system further.

The difference between 2.1 bdb and 2.2 bdb might come from several improvements such as
the transaction backoff and not doing the dn2id indexing for the suffix entry (esp. when
the underlying database is large).
It also seems that the context CSN code is not a severe bottleneck because 2.2 bdb
actually
ran more than twice faster than 2.1 bdb. - but to make sure, I think it required to
harness the backend
with tests having higher concurrency.

HDB's improvement over BDB shows that the hierarchical structure
of the directory and the backend implementation matches very well....