Oracle ESB performance enhancements

Because the growth in the number of messages that one of our customers is receiving on it’s Oracle ESB, they were looking into how to enhance it’s performance. Oracle came up with the following clues:

  • Upgrade SOA Suite to a higher patch level
  • Reduce logging (including instance tracking in ESB)
  • Increase the number of listeners in ESB on Queues
  • Turn off payload validation

In order to see what these could do for them we did some loadtesting. The upgrade to a higher patch level of SOA Suite was needed at least to get the ESB working correctly with the configured number of listeners. However because of some issues running Oracle Universal Installer there wasn’t any time left to verify that the patch resulted in increased performance.
For functional and application management reasons turning of logging was not considered an option at this stage.

Increase the number of listeners in ESB on Queues

set ESB listeners in console

set ESB listeners in console

For each ESB System the number of listeners can be configured. These listeners are used to read from JMS topics. If there is only one listener (which is the default) message are read from the JMS Topic one at a time. The first screenshot shows where to set the number of listereners using the ESB Console.

Average response time

Average response time


To determine the optimum number of listeners for the specific ESB, OS, hardware combination we did some loadtesting. The results for the average response time are shown in the next screenshot.

As expected the respons time increases at a certain point when the number of listeners is raised.

With 90% and max response time

With 90% and max response time

“Time out” messages are never created by averages. While this first graph looks great and is very convincing, we are even more interested in the 90% and maximum respons times. A chart for these statistics has been included as well. Analyzing this graph one can conclude that this has an even stronger support to set the number of listeners to an appropriate level.

From this experiments it can be concluded that the response time can significantly be reduced by setting the number of listeners of an ESB system to the appropriate level. The maximum respons time has can be decreased by over 50%. This has a significant impact on the availability of the services exposed using the ESB.

Turn off payload validation

Turn off payload validation

Turn off payload validation


Another idea to enhance the performance is to turn off payload validation. Needless to say that this also has functional aspect. In most cases the validation that is performed here has some kind of business (related goal), like data quality. To switch it off, has impact, and the validation has te be migrated to some place else in the software.
Response time

Response time


The performance results can be dramatic. In a positive way! As is shown in the figure on the right, the respons time can be reduced to a fifth of the original. This goes for both the average and the maximum respons times.

If you can change your service so payload validation at this point is no longer required, this is a great step in enhancing the Oracle ESB’s performance.

9 thoughts on “Oracle ESB performance enhancements

  1. Narasimha Kamath

    Hi Peter,
    Thanks for the good post.I wanted to know about oracle SOA suite 10gR3 (10.1.3.4) with MLR#4.Most of our system created have default value of 1 , how do i come to know for a given environment what is the approximate number of listener required.

  2. PeterPaul Post author

    When creating an ESB system the number of listeners is defaulted 1.
    The required number of listeners depends on several factors, ranging from number of services and adapters to underlying OS and hardware. Sources at Oracle point out that the number of listeners varies for most ESB systems from 20 to 50. To determine an optimal value for this customers system we did some loadtest. The aggregation of the results was shown in the diagram in the blogpost.

  3. Narasimha Kamath

    Hi Peter,
    Thank you very much for the quick reply.I will try to perform the load testing and come up with the proper value as you have mentioned.

    I have One more question to ask, Is 10.1.3.5 a stable version ?.Definately we will do all the required testing,All I wanted to know is whether 10.1.3.5 is as stable as 10.1.3.4?.

  4. steve

    Hi Peter,
    Thanks a lot. for such a good post…
    can u please specify that response time mentioned here is calculated from where.
    Is it the average of all the summation of processing time of a instance.

    -regards
    steve

  5. PeterPaul Post author

    @Narasimha Kamath
    I have not yet installed 10.1.3.5 myself. I don’t see any reason why it should be less stable than 10.1.3.4. Some people consider this an in between version that enables customers to run SOA Suite in a supported wayon a recent Weblogic version (although no confirmation seen of this on metalink).

    Good luck!

  6. PeterPaul Post author

    @steve
    Hi Steve,
    Jmeter was used to test and measure respons times. So typically measured from the client side.
    The measurements where on async web services. So there was a queue between the web service called by the client and back end systems. This buffers results in a scenario where a “respons” was given back to the client, and it still can take time to process the message into the back office systems.

    There is 1 graph displaying the average respons time, and 1 that includes the 90% and max respons time numbers. The latter are very important since time outs are never occur at average respons times 😉

    hth

  7. PeterPaul Post author

    Hi Doug,

    We have no experience with VTD-XML. As far as I understand it VTD-XML could give some relieve if your system is bound on CPU or RAM on the XML parsing part.

  8. Pingback: deltalounge » Oracle ESB using AQ on AIX – performance boost

Leave a Reply

Your email address will not be published. Required fields are marked *