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 18:58:58 GMT
On 10/01/12 13:45, Andy Seaborne wrote:
> 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
> 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!
> Andy


Could you profile the tests and pass on the results?  Any testing code 
left should show as hotspots.


View raw message