6 Replies Latest reply on May 20, 2010 12:18 PM by Andrig Miller

    How can you turn of EJB 3 invocation statistics

    Andrig Miller Apprentice

      I was wondering how you can turn of EJB 3 invocation statistics (number of calls, min and max response times, etc., that show up in the MBean view).

       

      It doesn't seem to be documented anywhere.

        • 1. Re: How
          Carlo de Wolf Master

          http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas?view=revision&revision=57901

           

          You can't. And since the InvocationStatistics is mostly synchronized methods it forms a natural bottleneck in the flow.

          • 2. Re: How
            Andrig Miller Apprentice

            Carlo de Wolf wrote:

             

            http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas?view=revision&revision=57901

             

            You can't. And since the InvocationStatistics is mostly synchronized methods it forms a natural bottleneck in the flow.

            Any plans to change this?  I could take a look at it, if not.

            • 3. Re: How
              Carlo de Wolf Master

              First I want to see some measurements to know the extend of the problem and to have a base of comparison.

              • 4. Re: How
                Carlo de Wolf Master

                Most likely the fix will use an statistics object wrapped in an AtomicReference.

                • 5. Re: How
                  Andrig Miller Apprentice

                  Carlo de Wolf wrote:

                   

                  First I want to see some measurements to know the extend of the problem and to have a base of comparison.

                  I agree.  In looking at the code, all the action is in ServiceContainer and InvocationStatistics.  I will do some timings on the baseline, and then remove the invokeStats object completely, so I can see a delta.  To get enough concurrency to make it reasonable, I might borrow a large machine from the RHTS, so we could measure with 100's or even a 1,000 concurrent threads.  So, I'll try to get some comprehensize measurements, so we can quantify the overhead.

                  • 6. Re: How
                    Andrig Miller Apprentice

                    Carlo de Wolf wrote:

                     

                    First I want to see some measurements to know the extend of the problem and to have a base of comparison.

                    Well, I did measurements.  I ran a test with 5 stateless session beans that did nothing but call each other and return.  I did this on a 8 core system with Hyperthreading (16 virtual cores), at 600 users with no think times.  Just hammer the server.

                     

                    In that test, I could only measure an average of 1.33% difference between running with the statistics, and running with a patched server with all statistics completely removed from the container.

                     

                    After going through the trouble to remove the statistics competely from the container, the results make sense to me know.  The reason I thought this might be an issue is a customer had e-mailed me saying he thought it was a bottleneck.  I need to get back to him, and see why he thinks that is true, and what he is seeing.  My tests simply don't back that up.  In the code, we are already using volatiles for all the counters, and a ConcurrentReaderHashMap to store the instances of the InvocationStatistics object (which makes complete sense in that you only create the instance once and store it once, and the rest of the time is spend getting from the HashMap).  The only synchronization, that seemed problematic, is in the "concurrent calls" code (callIn, callOut methods), but my test proves its not a real issue.

                     

                    So, I'll turn my attention elsewhere.