[jesper.pedersen]

The IronJacamar test suite uses the Volatile store, and there are log entries @ TRACE from com.arjuna, but maybe it could be of benefit to log the full configuration of the transaction manager @ DEBUG once started.

[marklittle]

I shouldn't need to enable logging at all to see the difference. I'll let you know how I get on.

[jhalliday]

Have you got evidence it is actually a locking issue? You'll see the same throughput bottleneck if you simply don't have enough client threads to keep the system busy, what with most of them being asleep for several ms.  When doing the last round of perf work a few years back I was up into the high hundreds of clients for similar tests and having to tweak jvm stack sizes to get the tests to run in a reasonable amount of RAM...

[tomjenkinson]

Is it possible that this is a 1PC transaction though? In which case the object store would make no difference.

[marklittle]

Yes, you are right in that with 1PC the object store shouldn't even be involved in this scenario.

I've added some basic examples (not using JCA) into the com.arjuna.ats.jta.xa.performance package within JTA. Here are some indicative figures to illustrate some points:

OnePhasePerformanceVolatileUnitTest forces the Volatile object store and then runs 10 threads for 1000 transactions in each thread, with a single XA resource within each transaction:

ObjectStore used: com.arjuna.ats.internal.arjuna.objectstore.TwoPhaseVolatileStore

time for 10000 write transactions is 275

number of transactions: 10000

throughput: 36363.637

OnePhasePerformanceDefaultUnitTest is the same but uses the default log implementation (ShadowNoFileLockStore in this case):

ObjectStore used: com.arjuna.ats.internal.arjuna.objectstore.ShadowNoFileLockStore

time for 10000 write transactions is 325

number of transactions: 10000

throughput: 30769.23

Now these figures should be pretty much the same and I know there's no log activity going on so perhaps this difference (about 15%) is due to initialisation. But read on ,,,

OnePhase2PCPerformanceVolatileUnitTest is similar to above but this test disables the 1PC optimisation so there is a log involved this time:

ObjectStore used: com.arjuna.ats.internal.arjuna.objectstore.TwoPhaseVolatileStore

time for 10000 write transactions is 356

number of transactions: 10000

throughput: 28089.887

And OnePhase2PCPerformanceDefaultUnitTest does the same but with the default log implementation:

ObjectStore used: com.arjuna.ats.internal.arjuna.objectstore.ShadowNoFileLockStore

time for 10000 write transactions is 2345

number of transactions: 10000

throughput: 4264.392

Hope this helps.

[jesper.pedersen]

Thanks Mark, I'll take a look.

The submitted PRs are still valid though.

[tomjenkinson]

Hi Mark,

I managed to get more consistent numbers in your unit test:

ObjectStore used: com.arjuna.ats.internal.arjuna.objectstore.ShadowNoFileLockStore

time for 1000000 write transactions is 2945

number of transactions: 1000000

throughput: 339558.56

ObjectStore used: com.arjuna.ats.internal.arjuna.objectstore.TwoPhaseVolatileStore

time for 1000000 write transactions is 2886

number of transactions: 1000000

throughput: 346500.34

To do this I ran a single TX through the system before beginning the timings. I also run for 100000 units of work. We do have a performance harness which supports this ramp up business so I will point Mike at your new tests and see if we can get them into that too.

As your test shows, the cost of logging significantly dwarfs a lot of the optimizations around the side we can often make. That being said I am very interested in ones that reduce object count as I can totally appreciate that a consistent running speed is really beneficial too. James (this years student) is currently working on an object store that uses infinispan and we are seeing some early signs of performance wins there (paying attention to reliability considerations).

Thanks,

Tom

[tomjenkinson]

Looking through [JBTM-2208] Removed unused method from ActionManager - JBoss Issue Tracker I can't see any reference to the class elsewhere in the code base so I agree we should remove the dead code.

[tomjenkinson]

Unfortunately our CI did not show this pull request having a significant performance improvement. If you believe our performance testing is not adequate in this area please do feel free to continue the discussions on our forum. We could look to add further tests that you might recommend so as to see the improvement.