Re: dissection of search latency

[Lawrence Greenfield <leg+@andrew.cmu.edu>]

A search with no indexing isn't a very interesting benchmark; this
isn't what we should be optimizing for.

Berkeley db with txns is fairly slow at iterations, though 0.5 seconds
to iterate across 10000 entries seems pretty bad.  Is there any
locking going on besides the internal locks in Berkeley db?  (On the
plus side, the Berkeley db code will allow multiple iterators
simultaneously.)

Also, Berkeley db does internal caching; no I/O goes on the second
time around anyway.

But really, if we're going to optimize, we need realistic benchmarks.

Larry

   From: "Jonghyuk Choi" <jongchoi@us.ibm.com>
   Date: Wed, 14 Nov 2001 16:54:47 -0500

   Below is a dissection of search latency.

   - Test Environment

   directory data : 10011 entries (from DirectoryMark dbgen tool)
   cache size : 10011 entries
   dbcache size : 200MB
   no indexing
   single search for an entry using the filter 'cn=Audy Flansburg'
   (s = seconds, m = milliseconds, u = microseconds)
   * cold run : all data from disk,    warm run : all data from entry cache