I have to correct my statement below, I was misreading my own numbers. The
overall write time was about 3 times slower, not just 70%. This is
comparing the latest build, once with and once without transactions (single
user). The numbers (40%) I mentioned before came from 25 concurrent users
on a build using transactions from May 15 compared to a build using
transactions from last weekend. That is not quite the same kind of
comparison of course. However, I do recall (I don't have that on paper)
that my own test suite with the May 15 build was running at a comparable
speed whether I was using transactions or not. So I dare to conclude that
write transactions are now considerable more expensive than around May 15
Simon
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Simon Helsen/Toronto/IBM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[email protected]
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[email protected]
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|06/13/2012 01:08 PM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: concurrency and slower results
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
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
>
>
>
