1 2 3 Previous Next 38 Replies Latest reply on Jun 28, 2016 9:30 AM by Thomas Jenkinson Go to original post
      • 30. Re: Call stacks of begin, enlistResource and commit
        Jesper Pedersen Master

        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.

        • 31. Re: Call stacks of begin, enlistResource and commit
          Mark Little Master

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

          • 32. Re: Call stacks of begin, enlistResource and commit
            Jonathan Halliday Master

            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...

            • 33. Re: Call stacks of begin, enlistResource and commit
              Thomas Jenkinson Master

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

              • 34. Re: Call stacks of begin, enlistResource and commit
                Mark Little Master

                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.

                • 35. Re: Call stacks of begin, enlistResource and commit
                  Jesper Pedersen Master

                  Thanks Mark, I'll take a look.

                   

                  The submitted PRs are still valid though.

                  • 36. Re: Call stacks of begin, enlistResource and commit
                    Thomas Jenkinson Master

                    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

                    • 37. Re: Call stacks of begin, enlistResource and commit
                      Thomas Jenkinson Master

                      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.

                      • 38. Re: Call stacks of begin, enlistResource and commit
                        Thomas Jenkinson Master

                        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.

                        1 2 3 Previous Next