IBM Integration Bus V10 Performance Testing Samples

IBM Knowledge Center

The attached IIB V10002 Project Interchange (PI) file (IIBV10002PerformanceSamples.zip) includes the applications used to produce the IIB V10 Performance Reports. The PI file contains the following applications:

  • Aggregation Sample
  • Coordinated Request Reply Sample
  • File Out File In Sample
  • Large Message Sample
  • Routing Cache Sample
  • SOAPConsumer
  • SOAPProvider
  • Transformation Sample
  • RESTful API Sample
  • ISO 8583 Sample

There are also several libraries which contain the associated schemas and message sets.

In addition to the above, is an "Independent Resources" folder which contains the input messages (256byte, 2k and 20k) for the above applications, as well as MQ and Database configuration information.

The 2nd attachment (IIBV10002PerformanceSamplesRunConfigurations.zip) is a set of "run configurations", that once the JMSPerfHarness performance test client jar is copied into the workspace, will performance test each application above.

This document describes the setup and invocation of the above performance applications within the IBM Integration Toolkit on the Windows platform. However, running them on other platforms is as simple as creating a broker on a remote environment and deploying directly to it.

Setup

In order to run these samples, install IBM Integration Toolkit and runtime V10.0.0.2, and download IIBV10.0.0.2PerformanceSamples.zip and IIBV10.0.0.2PerformanceSamplesRunConfigurations.zip.

Sample Artefacts

Download these zip files:

IIB V10.0.0.2 Performance Samples PI

IIB V10.0.0.2 Performance Samples Run Configurations

Follow these steps to import the sample artefacts:

  1. Start the toolkit specifying a new workspace.
  2. Go to menu "File" Import, select "Other Project Interchange" and click Next.
  3. Select IIBV10.0.0.2PerformanceSamples.zip as the value for "From zip file", ensure all projects are select and click Finish.
  4. Using an unzip program, unzip the file IIBv10.0.0.2PerformanceSamplesRunConfigurations.zip. A directory called "IIBv10.0.0.2PerformanceSamplesRunConfigurations will be created containing several "*.launch files.
  5. Go to menu "File" Import, select "Run/Debug" Launch Configurations" and click Next.
  6. Select the directory IIBv10.0.0.2PerformanceSamplesRunConfigurations created by unzipping the file above as the value for "From Directory", ensure the directory and all "*.launch files are selected and click Finish.
  7. Click the following icon to go to the "Integration Development perspective:

 

Performance Harness

Follow these steps to import the PerfHarness jar:

  1. Go to the GitHub perf-harness repository releases https://github.com/ot4i/perf-harness/releases
  2. Download the "Perfharness.zip" from the latest release.
  3. Unzip this file.
  4. Drag and drop the perfharness.jar file to the "Independent Resources" PerfHarness Java project in the workspace.

In addition, to run JMSPerfHarness using MQ, it must have the MQ JARs available. Each run configuration has a link to the "PerfHarness Java project to pick up any associated JAR files.

For example:

 

"Right-click on the "PerfHarness Java project, select "properties and then "Java Build Path". Ensure the directory is correct for the com.ibm.mq.jar and jms.jar JARs:

 

If you are going to be running any of the samples that require MQ (Aggregation, Coordinated Request Reply, FileOutFileIn, ISO8583, Large Message, Routing Cache and Transformation) then you will need a integration node with a default queue manager. To create this please follow the sections below - Default Configuration & MQ Resources. If you only want to use the HTTP/SOAP based samples you can use the built in TestNode_{username}

Default Configuration

Create a Queue Manager


  1. From a command console run "crtmqm TestNodeQM"
  2. Start the queue manager, run "strmqm TestNodeQM"
  3. Create the Integration Node queues, run "<IIB-InstallDir>\server\sample\wmq\iib_createqueues.cmd TestNodeQM"
  4. Update the queue manager listener port "echo alter LISTENER(SYSTEM.DEFAULT.LISTENER.TCP) TRPTYPE(TCP) PORT(2414) CONTROL(QMGR) | runmqsc TestNodeQM"
  5. Start the queue manager listener "echo start LISTENER(SYSTEM.DEFAULT.LISTENER.TCP) | runmqsc TestNodeQM"
  6. If you are running against MQ8 you may also need to run:
    • echo ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)| runmqsc TestNodeQM
    • echo REFRESH SECURITY TYPE(CONNAUTH) | runmqsc TestNodeQM

Create the Integration Node


  • Go to Integration Nodes view
  • Right click “Integration Nodes", select “New” then "Local Integration Node".

  • Insert the name of the Integration Node (TestNodeMQ) and default queue manager (TestNodeQM)
  • You should now see TestNodeMQ in the “Integration Nodes” view, including the integration server called default.

MQ Resources

Create the MQ resources required to run the performance samples:

  1. Start an IIB console window.
  2. Type runmqsc TestNodeQM
  3. Copy the contents of the file create_MQ.mqsc, from the “Setup and Configuration” folder in the workspace.

  1. Paste the MQ commands into the console window.
  2. Type end to complete the updates.

File node directory setup

In order to run the File Out File In performance application, the following environment variable needs to be configured for the broker.

  1. In the directory C:\ProgramData\IBM\MQSI\common\profiles, create a new file call performanceTests.cmd.
  2. Edit performanceTests.cmd, adding the line

set MQSI_FILENODES_ROOT_DIRECTORY=c:\temp

  1. Create the following directory structure c:\temp\file\input
  2. Stop the broker by running mqsistop TestNodeMQ.
  3. Start the broker by running mqsistart TestNodeMQ.

DB2 Resources

Only follow this step if you plan to deploy and test the DataWarehouse Sample.

The Routing Cache Sample requires a database called USERDB and a table called routing_table to be configured. These instructions assume this will be done in DB2, however an alternative database can be used.

  1. Start the “DB2 CommandLine Processor” window

  1.  Run the commands in the create_db2_tables script from the “Setup and Configuration” folder in the workspace.

  1. Type quit to complete the updates.
  2. Start an IIB console window.
  3. Run the following command to setup the database userid and password: mqsisetdbparms TestNodeMQ –n USERDB –u <userId> -p <password>
  4. If running the File Out File In performance application, go to the next section, otherwise stop and start the broker here:
    1. Stop the broker by running mqsistop TestNodeMQ.
    2. Start the broker by running mqsistart TestNodeMQ.
  5. Next we must had a system ODBC referance for USERDB. On windows this is done by launching the ODBC panel (Control Panel-Administrative Tools-ODBC Data Sources (64-bit). Once open select the System panel as shown below

  6. Select "Add" and select your DB2 Instance

  7. Select the USERDB instance and give it a "Data Source Name" of USERDB, Select "Add" and select your DB2 Instance

  8. Once you have completed this it should be listed in your "System Data Sources"

Global Cache Setup

The Coordinated Request Reply sample uses the global cache for storing its transient data. By default the global cache is disabled on an Integration Server. To enable it run the following commands

  1. mqsistop TestNodeMQ
  2. mqsichangebroker TestNodeMQ -b default
  3. mqsistart TestNodeMQ

REST API Setup

RESTful API sample requires the Integration Node to be configured to user the Intergration Server HTTP Listener. If you have a default queue manager, by default the HTTP nodes will use the Integration Node wide listener. If there is no default queue manager there no extra configuration is required. To update the configuration to use the Intergration Server HTTP Listener run the following commands

  1. mqsistop TestNodeMQ
  2. mqsichangeproperties TestNodeMQ -e default -o ExecutionGroup -n httpNodesUseEmbeddedListener -v true
  3. mqsichangeproperties TestNodeMQ -b httplistener -o HTTPListener -n startListener -v false
  4. mqsistart TestNodeMQ

SOAP Consumer and Provider setup

The SOAPProvider application consists of:

It can simply be deployed to the integration server default. It listens on the default SOAP 7800 port. The URL is /SoapProvider.

The SOAPConsumer application consists of:

It relies on calling the SOAPProvider application using the SOAP Request node. The SOAPConsumer application should be deployed with the SOAPProvider application to the integration server default.

The SOAPConsumer application listens on the default SOAP 7800 port, its URL is /SoapConsumer. The SOAP Request call is made to http://localhost:7800/SoapProvider which is assumed to be the SOAPProvider application.

Note: When the IBM Integration Bus Performance team test the SOAPConsumer application, the SOAPProvider application is deployed to a remote machine, which more closely resembles customer scenarios. This can easily be achieved by creating an additional broker on the remote machine and deploying the SOAPProvider application separately from the SOAPConsumer application. Within the SOAPConsumer application, the “Web service URL” value, on the “HTTP Transport” tab of the SOAP Request node will need to be changed to refer to the location of the SOAPProvider application.

RESTful API setup

The RESTful API (REST_TransactionService) relies on calling a backend SOAP_TransactionService from a SOAP Request node. The SOAP_TransactionService application should be deployed with the REST_TransactionSercice to the integration server default.

The SOAP_TransactionService listens on the localhost:7800/TransactionServiceSOAP 7800 port. The SOAP Request nodes makes requests to this URL with "makePayment" and "retrieveTransactions" operations which is assumed to be servied by the SOAP_TransactionService.

Note: When the IBM Integration Bus Performance team test the REST_TransactionService, the SOAP_TransactionService is deployed to a remote machine, which more closely resembles customer scenarios. This can easily be achieved by creating an additional broker on the remote machine and deploying the SOAP_TransactionService separately from the REST_TransactionService. Within the REST_TransactionService, the “Web service URL” value, on the “HTTP Transport” tab of the SOAP Request node will need to be changed to refer to the location of the SOAP_TransactionService.

IIB Performance Tuning

The following performance tuning will help improve message rates and response times:

  • mqsichangeproperties TestNodeMQ -e default -o HTTPConnector -n maxThreads -v "200"
  • mqsistop TestNodeMQ
  • mqsistart TestNodeMQ

Running the performance applications

Each of the performance samples is packaged as an integration application.

  1. View the performance applications in the integration toolkit.

  1. To deploy one of the applications to the broker runtime, simply drag and drop the application to the integration server called default.

  1. The application will be deployed.

  1. Then go to the Run menu within the Integration Toolkit, and select “Run Configurations”.

  1. Expand the “Java Application” section, and select one of the Aggregation tests, followed by clicking Run.

  1. Several prompts will appear, displaying default values. The defaults values may be different if an alternative or remote broker and queue manager are deployed to. For the queue manager (IB9QMGR) listener port, change or accept the default, and click OK.

  1. For the queue manager name (IB9QMGR), change or accept the default, and click OK.

  1. For the host name (localhost), change or accept the default, and click OK.

  1. For the number of client threads that put and get messages, change or accept the default, and click OK.

  1. For the test run length in seconds, change or accept the default, and click OK.

  1. Performance Harness will then run and report the message rate every second, with a final summary.

The output is described as:

  • Rate is the average number of transactions per second (TPS) for all threads. This is displayed according to the –ss flag on PerfHarness, the default is every 5 seconds.
  • Threads is the number of client threads running inside PerfHarness. Each thread puts a request message and waits for a response. The default is 10. The user is prompted to change this value.
  • totalIterations is the total number of messages processed in the run.
  • avgDuration is the length of run in seconds. It is fractionally greater than 60 seconds due to the time taken starting the threads. There is a small pause between each thread started.
  • totalRate is the average TPS across the run.

Repeat this process for the other performance applications. Ensure only 1 application is active at a time, as they share MQ queues. Either delete or stop applications not being tested.

Note: All of the MQ based applications use the same input and output queues so you can only have 1 of them deployed at any one time.

Further performance tuning

  • If running persistent messaging tests, refer to performance report for additional queue manager tuning.