Integration Bus v10 was released in March 2015 and contained significant changes to improve performance for existing workloads migrated onto the new version.

As well as reducing the CPU cost of processing a transaction, there have been significant improvements in the cost and speed of operational changes, plus a reduction in the footprint of the product when installed (both in memory and disk). These improvements apply to existing integration solutions and do not require re-coding to get the benefit of the new version.

Significant changes which affect message flow processing, in terms of CPU cost per transaction compared to v9:
– Parsing of non-XML data using DFDL: 20% lower CPU/transaction
– Accessing a database from a Graphical Map: 10% lower CPU/transaction
– Parsing of JSON data: 18% lower CPU/transaction
– Processing raw HTTP requests and SOAP webservices over HTTP: 5% lower CPU/transaction
– SOAP web services over MQ: 10% lower CPU/transaction
– Receiving and sending files using MQ File Transfer Edition: 18% lower CPU/transaction
– Use of static initialisation of ESQL variables: 50% lower CPU/transaction

There have been some changes to default values for TCP/IP tuning (tcp noDelay parameter and connection persistence) which means that existing scenarios using TCP, SOAP and HTTP nodes are set to optimum values by default, rather than requiring change for production scenarios – so it is easier to achieve optimum performance in v10.

In addition to these changes, response time for administrative actions has been reduced in v10:
– Starting and stopping an integration node is up to 23% faster
– Connecting an administrative application and deploying is up to 33% faster

The v10 package size has been significantly reduced compared to the previous version; minimum download size for the installation image is 60% smaller on developer platforms, speeding up the provisioning of new images. Server-only platforms also benefit from a slightly smaller package size and simpler, faster installation mechanism.

This set of improvements should result in meaningful improvements for users migrating to v10 even before taking advantage of any new function in the latest release.

The details documented above are gained from testing that was carried out on the first v10 release from March, and comparisons are relative to the initial v9 release.

4 comments on"V10 Performance Highlights"

  1. Hi Team,
    Can you please help in knowing the performance improvement in mapping node in IIBV10 .Is there any guideline which I can refer to filter use case where I can apply mapping rather than esql without having significant performance(throughput time,memory use,cpu usage) overhead

    • Hi,

      Unfortunately we don’t have performance data for the mapping node in V10. Given the same code mapping will usually be slower than ESQL as it has ever overheads involved. The exact overhead can vary depending on the workload and best diagnosed by running some actual performance tests with your same data.

  2. iibanalyst June 07, 2018

    Do we have performance improvement on DB interactions such as INSERT, SELECT ?

    • Hi Sakthivel,

      We have made no specific improvements for INSERT or SELECT although there may be some very minor improvements as a result of the overall version upgrade

Join The Discussion

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