[Date Prev][Date Next]
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 Hyuk Choi
IBM Thomas J. Watson Research Center
Enterprise Linux Group
Lawrence Greenfield <firstname.lastname@example.org>@OpenLDAP.org on 2001-11-14
Sent by: owner-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" <email@example.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
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