I was actually able to run a bunch of simpler tests with no concurrency and compare the exact same implementation of our product with (tx) and without transactions (vanilla) and it seems that the time is going to write activities. In my suite, it took Tx about 70% longer to write the same data. In these non concurrency tests, queries were running with roughly the same speed. I assume that the slowdown on queries with 25 users is caused by lock contention on the writes which are taking much longer for some reason
Simon From: Laurent Pellegrino <[email protected]> To: [email protected] Date: 06/13/2012 11:10 AM Subject: Re: concurrency and slower results Hello, I also noticed the same thing by updating jena-tdb only. I switched from version 0.9.0-incubating to snapshots on 6 June and I noticed around ~50% decrease on one of our benchmark which is read/write intensive. Kind Regards, Laurent On Wed, Jun 13, 2012 at 4:33 PM, Simon Helsen <[email protected]> wrote: > before you ask, of course, we are looking into whether this is something > on our end. We only made very few changes, but we should be able to > isolate this. I'll report on that once I know for sure. My question was > more whether anyone knew of any changes in tx that could affect concurrent > performance negatively since May 15 > > thanks > > Simon > > > > > > From: > Simon Helsen/Toronto/IBM@IBMCA > To: > [email protected] > Date: > 06/13/2012 10:09 AM > Subject: > concurrency and slower results > > > > hi everyone, Andy especially, > > it looks like some of the changes to TDB since May 15 have negatively > affected the concurrent behavior of Tx. To clarify, we are doing some > serious internal performance testing on a product which is based on > Jena/TDB. We initially did these runs to compare Tx (2.7.1 snapshot of May > > 15) with our old TDB implementation (which used a conservative locking > model). The results were good, especially with long-running/expensive > index update operations. > > Now, I had asked the performance team to rerun their tests with a new > build of the product based on the release candidate (of last weekend) and > they are reporting a concerning degradation. Compared to the May 15 TDB, > they are reporting 12-15% decrease in query performance when doing a > "light update load" and about 40% query and 40% update performance > degradation when doing a "heave update load". > > That is quite a serious regression. The question is what changed since May > > 15 that could have such a bad effect on performance. The tests included > only 25 concurrent users on about 15 million triples. Yet, I wonder if > some of the recent lock changes (see JENA-252) are responsible > > thanks > > Simon > > >
