3 Replies Latest reply: Mar 19, 2013 7:47 AM by Anuj Dwivedi RSS

    B2B/JMS Performance Tuning

    894980
      Hello All,

      We have a use-case in which an SOAP message will be received by OSB proxy service. The 3 step process is described below:
      1. OSB will extract EDIFACT message from request and write it to the SOA JMS queue IE012_IN_Queue.
      2. B2B listeneing channel is configured to listen to IE012_IN_Queue and translate the EDIFACT to XML and send the translated message to another JMS queue IE012_Out_Queue.
      3. BPEL process reads XML message from IE012_Out_Queue and processes it further.

      Under load, we observe that this 3 step process is causing delay and processing is taking more time at one of the 3 points. We are unable to exactly say which one of the 3 steps is taking more time. Can anyone help me in this area ?


      Regards
      Aparna
        • 1. Re: B2B/JMS Performance Tuning
          Anuj Dwivedi
          You should measure/monitor the time taken in processing at each level. There are two ways to do it -

          1. Performance test, each and every part, separately
          2. Use below mechanisms for finding the processing time at all layers -

          a) At OSB, you may enable the action level monitoring and at OSB Dashboard, you may find out the average processing time of each service and action.
          b) At B2B layer, you may query b2b_instancemessage view(column PROCESSING_TIME) for each and every transaction and calculate the average processing time. Alternatively, you may use the B2B Metrics -

          http://docs.oracle.com/cd/E23943_01/user.1111/e10229/b2b_mtrx.htm#CHDFBCJH

          c) At SOA layer, again use the runtime tables (composite_instance and cube_instance) to calculate the average processing time or use the EM console.

          Regards,
          Anuj
          • 2. Re: B2B/JMS Performance Tuning
            894980
            Hi Anuj,

            Thanks for the reply. After following your approach, I see that the JMS part is working fine, but the messages are being batched in B2BEventQueue. Based on information from other blogs i found that b2b.inboundthreadCount, b2b.outboundThreadCount, b2b.defaultThreadCount values have to be set to improve the performance. I have set these thread counts to 4,4,2 respectively and ran some load testing. I see that message processing time in B2B has now come down to 2-4 seconds. Is it still possible to refine this processing by tuning some other parameters? I am executing the tests with a 6 KB EDIFACT message.

            Regards
            Aparna
            • 3. Re: B2B/JMS Performance Tuning
              Anuj Dwivedi
              Hi Aparna,

              You may refer -

              http://docs.oracle.com/cd/E23943_01/core.1111/e10108/b2b.htm#BGBGHAHF

              Few basic recommendations -

              1. Domain must be running in production mode
              2. Both server and component level logging should be set to error/warning to avoid excessive logging
              3. Monitor DB and make sure that SQL's are performing good (You will need AWR and ASH reports of DB for this. You may take help from any DBA in your org)
              4. SOA must be running in a cluster and all the servers of the cluster must be up and running
              5. Monitor the data-sources (specially SOA datasource) and make sure that enough connections are available to handle the load
              6. Make sure that JTA timeout and XA transaction timeout (set in data-source) are set to a proper value (Weblogic JTA timeout< DataSource XA Transaction Timeout < DB distributed_lock_timeout)
              7. It is recommended to use Exalogic and Oracle RAC DB for high volume production deployments

              I believe that if all above points are taken care of then B2B should be able to process small messages (like 6KB in your case) within few milliseconds. If still you hit a performance issue then better log a SR with support and after screening your system, they may suggest more fine tuning at pain points. Remember that each and every production deployment may be unique because of the requirements and resources available so generic recommendations may not solve the issue completely and hence screening of the specific system will be required to find the pain-points.

              Regards,
              Anuj