[Date Prev][Date Next]
back-bdb performance with SLAP_NVALUES
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
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.
slapadd time 33.9sec (with huge dbcache)
slapadd time 21m38sec (with small dbcache)
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
(phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979