[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Questions...
> -----Original Message-----
> From: Jong [mailto:jongchoi@OpenLDAP.org]
> > Load times for 1 million entries with "index objectclass,cn eq", and
> > execution times for test008 on these databases:
>
> test008 ran on top of the 1 million entry directory or with
> tests/data/test.ldif ?
test008 run over the 1 million entry database. I of course had to fix the
test input to use DNs in the test directory. I chose some search DNs in the
same part of the DIT as the write operations to increase contention, in
addition to a few that were more isolated.
> > 2.0 ldbm
> > 611.460u 106.700s 13:36.75 87.9% 0+0k 0+0io 24570pf+0w
> > real 8m20.289s
> >
> > 2.1 ldbm
> > 577.350u 111.690s 13:33.08 84.7% 0+0k 0+0io 24597pf+0w
> > real 8m54.929s
> >
> > 2.2 ldbm
> > 615.970u 113.240s 14:09.51 85.8% 0+0k 0+0io 24636pf+0w
> > real 8m59.085s
> >
> > 2.1 bdb
> > 1305.960u 25.130s 25:38.20 86.5% 0+0k 0+0io 193749pf+0w
> > real 0m23.964s
> >
> > 2.2 bdb
> > 1350.630u 28.200s 26:37.10 86.3% 0+0k 0+0io 204497pf+0w
> > real 0m10.335s
> >
> > 2.2 hdb
> > 1107.680u 22.890s 21:57.24 85.8% 0+0k 0+0io 185340pf+0w
> > real 0m9.704s
> >
> > The BDB/HDB tests were timed with transaction logging turned off.
> >
> > To recap the test008 scenario - 5 clients performing 1000
> reads of a single
> > entry, 5 clients performing 500 searches for a single
> entry, 4 clients
> > adding/deleting an entry (50 times) and 4 clients executing
> modrdn on an
> > entry (50 times). The load times for BDB/HDB can be further
> improved by using
> > more memory, but my test machine has only 768MB, and 384MB
> seemed like a
> > reasonable limit in this situation.
>
> besides memory, what is the spec for other things ? CPU ?
1.3GHz PIII CPU, running Linux 2.2.25 on ext2fs, Western Digital WD400BB on
ATA66.
> > Note that the fastest ldbm run time (8m20s) is over 200
> times slower than the
> > slowest bdb run time (0m24s), and back-hdb is about 500
> times faster than the
> > fastest ldbm.
> I've just tried to run test008 with my box (P4-2.4G) - with
> the test ldif file
> (tests/data/test.ldif).
> Both bdb and ldbm finished between 30 and 40 seconds...
> My test uses the default test setup - uses the default
> slapd.1.conf file generated by the
> test script.
slapd.conf:
database bdb
suffix o=Test,c=US
directory ./cens/db
rootdn o=Test,c=US
rootpw secret
#ldbm#dbnosync
#ldbm#dbnolocking
#ldbm#dbcachesize 402653184
index objectClass,cn eq
#bdb#idlcachesize 10000
DB_CONFIG:
set_lg_bsize 2097152
set_cachesize 0 402653184 0
set_flags DB_TXN_NOSYNC
set_flags DB_TXN_NOT_DURABLE
set_flags DB_REGION_INIT
set_lg_dir /var/tmp/logs
> The difference between ldbm and bdb became significant when
> indexing came into the picture.
Yes.
> So this may be a sign that we should improve the bdb indexing
> system further.
I agree, though I'm running out of ideas at the moment.
> The difference between 2.1 bdb and 2.2 bdb might come from
> several improvements such as
> the transaction backoff and not doing the dn2id indexing for
> the suffix entry (esp. when
> the underlying database is large).
> It also seems that the context CSN code is not a severe
> bottleneck because 2.2 bdb
> actually
> ran more than twice faster than 2.1 bdb. - but to make sure,
> I think it required to
> harness the backend
> with tests having higher concurrency.
The tests run nearly twice as slow with transaction logging enabled. I
believe, since the entry CSN is such a volatile datum, it should not be
explicitly recorded in the database. It generates needless transaction/log
overhead. As Kurt pointed out, it can be computed as needed.
> HDB's improvement over BDB shows that the hierarchical structure
> of the directory and the backend implementation matches very well....
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support