RE: test008-concurrency timings

["Howard Chu" <hyc@highlandsun.com>]

Forget this email; the test environment was unstable and the results are
invalid. Sorry about that. Stupid overheating pentiums...

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

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Howard Chu
> Sent: Tuesday, November 27, 2001 9:20 PM
> To: openldap-devel@OpenLDAP.org
> Subject: 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
>