back-bdb performance with SLAP_NVALUES

[Jonghyuk Choi <jongchoi@us.ibm.com>]

The performance of SLAP_NVALUES for DirMark messaging scenario :

1) SLAP_NVALUES w/o SLAP_NVALUES_ON_DISK
    DirMark : 2159.4 ops/sec min 0 max  36 avg 2 std 1
2) SLAP_NVALUES w SLAP_NVALUES_ON_DISK
    DirMark : 2186.5 ops/sec min 0 max 136.3 avg 1 std 1
3) no SLAP_nVALUES (and hence no SLAP_NVALUES_ON_DISK)
    DirMark : 2153.0 ops/sec min 0 max 31 avg 2 std 2

The numbers are averages of three runes.
# of entries : 10K
# of transactions : around 25 times the # of entries

Because the matching and normalization cost of DirMark messaging is not
significant, the performance improvement shown is not by a substantial
amount.
A small improvement is observed even in this case.

For the cases when the normalization cost is high
(such as DNs in the group member attribute) the performance benfits are
expected to be significant.

Below is the slapadd performance with / without SLAP_NVALUES_ON_DISK
together with id2entry.bdb and log file size.

SLAP_NVALUES_ON_DISK
id2entry.bdb 10320K
log 60.1M
slapadd time 33.9sec (with huge dbcache)
slapadd time 21m38sec (with small dbcache)

no SLAP_NVALUES_ON_DISK
log 55.8M
id2entry.bdb 7948K with SLAP_NVALUES_ON_DISK
slapadd time 32.6sec (with huge dbcache)
slapadd time 20m51sec (with small dbcache)

It seems that because of the db paging,
the increase in DB id2entry database size due to SLAP_NVALUES_ON_DISK
 is only by 30% and the increase in the log size is just by 7.7%.
The increase in slapadd time is less than 4% for both the dbcache cases.
The overhead of slapadd depends on the relative size of directory entries
to the db page size.

BTW, the overall slapd performance is up by 7~8%.
Looks like we gained this from refactoring...

------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box 218, Yorktown Heights, NY 10598
email: jongchoi@us.ibm.com
(phone) 914-945-3979    (fax) 914-945-4425   TL: 862-3979