directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject JDBM version & performances
Date Fri, 18 Jan 2013 08:54:09 GMT
Hi guys,

yesterday, while working on the issue we have when the server is
brutally shutdown, I noticed that we are using a version fo JDBM which
contains some code taht we don't need anymore (the Snapshot code). I
also did some experiment using the TransactionManager, with various
configuration. Here are some findings :

1) configuration impact

When we use the TM, we need to commit() all the modifications and to
sync the transactions peridodically. I tested many diffeent parameters,
like calling commit() for every modification, or once for 2
modifications etc (1, 2, 5,10, 20, 50, 100, 200, 500, 1000...). The very
same for the sync method with the same values (except that I always
start using the same number than the commit - it makes no sense to sync
more often that we commit - ).

The result is that with 200 modifications per commit, and 500 mods per
sync, I get a decent performance (less than 5% slower than not using a
TM at all). I think it's a good compromise as we don't have many pending
modification in case we have a crash.

There is one more parameter I haven't played with, the max number of mod
in a transaction (it should be >= nb mod per commit)

Now, we have to leverage those parameters, which means we should call
the commits() and sync() only when the syncWorker is kicked.

2) JDBM2 contains some extra code, as it's supposed to be a inmemory
MVCC BTree. We don't use this feature, but still, there is some extra
code called. I have conducted some performances on he old JDBM and teh
new one, and I was able to see that the old JDBM is 8 to 10 % faster
than the new one.

Considering that we don't need the Snapshot feature offered by JDBM2, I
think we should switch back to the old JDBM.

I still have to check that we don't have any impact when running
concurrent modifications, but this is just a safety belt here : the way
we fixed the issue is orthogonal.

I'll keep ou inform today.

Emmanuel L├ęcharny 

View raw message