Re: dissection of search latency

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

As Howard pointed, the directory under test was left non-indexed for fair
comparison.
We can analyze the indexed search performance as indexing becomes mature in
back-bdb.
The indexing analysis of back-ldbm alone may be of  help in finishing the
indexing of back-bdb.
- Jong

------------------------
Jong Hyuk Choi
jongchoi@us.ibm.com
IBM Thomas J. Watson Research Center
Enterprise Linux Group



Lawrence Greenfield <leg+@andrew.cmu.edu>@OpenLDAP.org on 2001-11-14
05:34:45 PM

Sent by:  owner-openldap-devel@OpenLDAP.org


To:   openldap-devel@OpenLDAP.org
cc:
Subject:  Re: dissection of search latency



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