incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: TDB: release process
Date Tue, 10 Jan 2012 13:45:50 GMT
On 09/01/12 15:07, Simon Helsen wrote:
> Andy, others,
> I have been testing TxTDB on my end and functionally, things are looking
> good. I am not able to see any immediate problems anymore. Of course,
> there may still be more exotic things left, but those can probably managed
> in am minor release. However, now that it is getting good on the
> functional end, I am starting to check the non-functional characteristics,
> especially speed and scalability (in terms of multiple clients). For this
> I use a test suite with about 35 different queries and I compare the
> performance against Jena 2.6.3/ARQ 2.8.5 and TDB 0.8.7 because that is the
> version we currently use in the release of our product.. I am comparing
> these numbers then with Jena/ARQ 2.7.0 and TDB 0.9.0 (20111229) and the
> transaction API. I realize this partially comparing apples to pears but
> from our perspective, we need to see how the bottomline changes in terms
> of query speed when we increase the number of concurrent clients.
> I have detailed numbers, but before I start sharing these, I want to know
> if there is anything I could/should do to tune ARQ/TxTDB in terms of
> performance. For instance, I wonder if there are still a whole range of
> checks active which I can/should turn off now that we are functionally
> more sound. For completeness, I should add that we don't use any
> optimization (i.e. we run with none.opt )
> thanks
> Simon


Figure would be good.  If you use TDB without touching the transaction 
system then it should be the same as before (with the obvious chances of 
unintended changes).  Have you run this way?

Just creating a transaction, especially one that allows write is a cost 
and if the granularity is small then it's going to make a big 
difference.  (This is one reason there isn't an "autocommit" mode - it 
only seems to end in trouble one way or another).  Read transactions are 
cheaper but not free.

In terms of tuning, TDB 0.9 needs more heap as the transaction 
intermediate state is in-RAM , with no proper spill-to-disk yet.

There shouldn't be the internal consistency checking enabled.  Hmm - 
better check yet again!


View raw message