directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Jdbm tests (micro benchmarks)
Date Fri, 14 May 2010 17:35:43 GMT
Hi guys,

today, I did some very basic tests with JDBM, trying to see what are the 
parameters we can play with in order to get the best performances out of 
this beast.

I'm playing with a 1 M elements base, all of them being String (a value 
between 0 and 1M for the key, transformed to a String, and 
"test<xxxxxx>" where <xxxxxx> is a random number).

I just played with the page size atm, to see what's the impact. I didn't 
changed any other parameters (like the internal MRU cache).

On my laptop, the best page size for insertion is something between 512 
and 2048, the difference is not really significant (it takes around 4 
seconds to do 1M inserts). When the number goes above or below, we 
quickly get bad numbers (up to 30 seconds when the page size is 4, 8 
seconds when the page size is 16, etc...)

The search give ssome very surprising results. When testing with 128 
values per page, creation takes 4.5 seconds, but searches takes 91 
seconds ! Going down to 16 values per page, creation takes 8 seconds, 
and searches takes 25 seconds (this is actually the best result).

The search is a bit different as I do 1M random searches, when the 
insertion is done by incrementing the key, so it's very likely that 
during insertion, the small MRU cache is hit a lot, when with random 
searches, we are having a lot of disk access. When doing sequential 
searches (from 0 to 1000000 as the key value), searches performances are 
way better.

I still have to do some more tests, I will post a graph on the wiki as 
soon as I have a complete sample.

I also want to play with some other parameters, like the cache size.

Last, not least, I need to do some profiling, because I just want to 
know what's going on internally. It's not normal that reads are almost 
as costly as writes ...

More to come.

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.nextury.com



Mime
View raw message