[Date Prev][Date Next] [Chronological] [Thread] [Top]

test008-concurrency timings

Out of curiosity I got execution times for running the tester in
test008-concurrency with various back-ldbm/back-bdb settings. I ran the
tests with slapd debug set to 0, otherwise the debug log file output
could skew the results. Otherwise the script is just modified by adding a
"time" command in front of the $TESTER invocation.

For back-ldbm, the results were fairly consistent:
real    4m11.254s		real    4m3.924s
user    0m0.550s
sys     0m0.440s
(Since the work is done in forked children, only the real time is of
interest.)

For back-bdb, no options
real    8m14.361s		real    7m56.679s
user    0m0.640s
sys     0m0.550s

back-bdb, dbnosync
real    7m31.627s		real    8m29.101s
user    0m0.750s
sys     0m0.430s
There appears to be no real value one way or another to this option. I think
the point is that the transaction log *must* get flushed sooner or later in
order for subsequent transactions to proceed.

back-bdb, dbnotxn
real    4m47.651s		real    5m28.831s
user    0m0.700s
sys     0m0.460s
This trades transaction semantics (locking on a per-operation basis) for
N-readers/1-writer semantics (locking per-database). Probably not a great
idea in general use, but it provides a reference point for the other
results. Theoretically, this ought to be about the same as regular
back-ldbm.

back-bdb, dirtyread
real    4m8.588s		real    5m17.011s
user    0m0.690s
sys     0m0.410s
This is a pretty significant improvement, putting back-bdb with transactions
back on par with back-ldbm's performance. What's interesting is that it can
be at least as fast or even faster than no transactions at all.

back-bdb, dirtyread, dbnosync
real    3m3.770s		real    3m31.418s
user    0m0.670s
sys     0m0.640s
The real kicker - combining dirtyread with the otherwise useless dbnosync
gets the best performance of all. Of course, you have no assurances that a
committed transaction made it onto the disk, but that's true for the
back-ldbm case here too. (back-ldbm is configured with dbnosync in this
test.)

It seems to me we should roll in both the DB_DIRTY_READ and DB_TXN_NOSYNC
behaviors for the "dbnosync" config keyword, and forget the other options.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support