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

Re: dissection of search latency

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

Jong Hyuk Choi
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
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

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.


   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