With this post, I will cover performance testing framework for Websphere Message Broker.

Tools Used:

Tools used to do the performance testing of ESB interfaces:

• Jmeter
• SupportPac IS03

The following section will brief the tools that are used in the ESB Performance test plans.

Jmeter:

Jmeter is an open source Apache Software used for load testing the applications. It’s a 100% pure java application for load and performance testing. It requires JDK 1.6 or higher. This is a Java desktop application with a graphical interface using the Swing graphical API, can therefore run on any environment / workstation accepting a Java virtual machine, for example: Windows, Linux, Mac, etc.

Protocols supported:

• Web: HTTP, HTTPS sites ‘web 1.0’ web 2.0 (ajax, flex and flex-ws-amf)
• Web Services: SOAP / XML-RPC
• Database via JDBC drivers
• Directory: LDAP
• Messaging Oriented service via JMS
• Service: POP3, IMAP, SMTP
• FTP Service.

Features:

• It’s free. It’s open source software.
• It has simple and intuitive GUI.
• JMeter can load and performance test many different server types: Web – HTTP, HTTPS, SOAP, Database via JDBC, LDAP, JMS, Mail – POP3.
• It is platform-independent tool. On Linux/Unix, JMeter can be invoked by clicking on JMeter shell script. On Windows it can be invoked by starting the jmeter.bat file.
• It has full Swing and lightweight component support (precompiled JAR uses packages javax.swing.* ).
• JMeter store its test plans in XML format. This means you can generate a test plan using a text editor.
• Its full multi-threading framework allows concurrent sampling by many threads and simultaneous sampling of different functions by separate thread groups.
• It is highly extensible.
• Can also be used to perform automated and functional testing of your application.

Setting up Jmeter:

• JMeter is a framework for Java, so the very first requirement is to have JDK installed in your machine. JDK 1.6 or above must be installed.
• Set the JAVA_HOME environment variable to point to the base directory location, where Java is installed on your machine.
• Append Java compiler location to System Path.
• Please download the Jmeter tool (link:http://jmeter.apache.org/download_jmeter.cgi).
• And unzip it and execute C:\apache-jmeter-2.9\apache-jmeter-2.9\bin\jmeter.bat.

IMPORTANT NOTE: JMeter currently knows to look for jars/classes in two places only:

• lib/ext, where the ApacheJMeter_*.jar files live
• lib, where the 3rd party jar files live

Due to the above limitations Additional jars should normally be placed in the lib directory. For example to establish the connectivity with Websphere MQ queues, All MQ jars (websphereMQ installationpath\java\lib) have to be copied to Jmeter lib directory.

Definitions: This sections Defines the terminologies that are going to be used most often in the further discussion of test plans.

Test Plan: TestPlan is where we create the real test plan for testing the performance. A test plan describes a series of steps JMeter will execute when run. A complete test plan will consist of one or more Thread Groups, logic controllers, sample generating controllers, listeners, timers, assertions, and configuration elements. Although test plan can have multiple thread groups but at least one thread group is mandatory.

Elements: Elements are the building blocks of a test plan. Elements of a test plan can be added by right clicking on the Test Plan node and choosing a new element from the “add” list.

Thread Groups:  Thread Group elements are the beginning points of your test plan. As the name suggests, the thread group elements control the number of threads JMeter will use during the test.

Samplers:  Samplers allow JMeter to send specific types of requests to a server. They simulate a user’s request to the target server. For example, you can add a HTTP Request sampler if you need to perform a POST, GET, DELETE on a HTTP service. Some other examples of samplers are: FTP Request, SOAP/XML Request, and JMS Request.

Listeners: Listeners let you view the results of Samplers in the form of tables, graphs, trees or simple text in some log files. They provide visual access to the data gathered by JMeter about the test cases as a Sampler component of JMeter is executed.

Listeners can be added anywhere in the test, including directly under the test plan. They will collect data only from elements at or below their level.

Message Flow Statistics Visualiser(IS03 SupportPac):

IS03 SupportPac runs as a java standalone application and uses MQ Client connection to connect Message Broker Queue Manager. It relies on the accounting and statistics facility of Message broker. So it has the ability to capture real-time and historic statistics data in tables, along with the capability to export all recorded data to CSV to enable custom user processing.

Setting up IS03 SupportPac:

There are a number of set up steps which must be carried out before IS03 will correctly function. These should be performed in the sequence listed in this document:

1) Ensure the Message Broker Queue Manager will accept client connections

• Configure and start a TCP Server-connection channel on the Message Broker Queue Manager.
• Configure and start a TCP Listener on the Message Broker Queue Manager.

2) Ensure that Message Flow Statistics are enabled.

• IS03 requires XML message flow statistics to be enabled for the flows you wish to visualise. Use the

‘mqsichangeflowstats’ command to configure this e.g:

mqsichangeflowstats MB7BROKER -s -g -j -n advanced -t basic -b basic -c active -o xml

• Visit the WebSphere Message Broker infocenter for more information on using this command:

http://www-01.ibm.com/software/integration/wbimessagebroker/library.

3) Configuring the ‘General Config’ settings.

The IS03 GUI provides a ‘General Config’ area (Figure 3.1) which allows you to configure how it connects to the Message Broker Queue Manager, along other configuration parameters.

Figure 3.1

Each of the configuration parameters are explained below:

• Queue Manager Hostname – The hostname or IP address of the system where the Message Broker Queue Manager is running. This parameter is required.

• Queue Manager TCP Port: The port which the Message Broker Queue Manager has a TCP Listener configured and running on (which was set up in step 1 above). This parameter is required.

• Queue Manager Name: The name of the Message Broker Queue Manager. This parameter is required.

• Server-connection channel name – The name of the Message Broker Queue Manager Serverconnection channel which should be used to connect. This parameter is required.

• Stats Subscription Topic: The name of the topic which IS03 will subscribe to in order to receive message flow statistics data. A default of ‘$SYS/Broker/+/StatisticsAccounting/SnapShot/#’ is specified which means that IS03 will receive SnapShot statistics for all running message flows, in any execution group. This default value can generally be left, unless you wish to subscribe to Archive statistics instead of SnapShot (In which case change it to: $SYS/Broker/+/StatisticsAccounting/Archive/# ). This parameter is required unless Stats Queue is specified. If both Stats Subscription Topic and Stats Queue parameters are specified, Stats Subscription Topic will take precedence and Stats Queue will be ignored.
• Stats Queue – Instead of gathering statistics data via the topic subscription mechanism, IS03 can read statistics data off a queue. This can be useful, for example, if you use a custom subscription to store statistics on queues for archiving purposes .By default, IS03 will perform a destructive GET when reading off the queue. To instead browse the queue, check the ‘Browse?’ option. This parameter is optional. To use it ensure that the Stats Subscription Topic field is cleared.

• Accounting Origin: If your flows use accounting origin, you can enter a value here to display only data for only the specified accounting origin. If this field is left blank, it will use the ‘Anonymous’ accounting origin (which is the default value WebSphere Message Broker uses if no Accounting Origin has been manually set). Note that if you want to have graphs which show data for two different accounting origins e.g. Company1 and Company2, you will need to run two instances of IS03, one configured to use Accounting Origin: Company1, and the other configured to use Accounting Origin: Company2. This parameter is optional.

ESB Performance test plans:

As we have gone through the briefing of Performance test tools. Next task is to build a performance test plan using the tools. Please find the explanation below for building the test plan.

Broadly Most of the ESB Interfaces can be categorized as Synchronous flows or Asynchronous flows.So to understand the Performance framework of ESB with Jmeter and supportpac let’s consider the most commonly used Scenarios Synchronous and Asynchronous ESB Flows.

Synchronous ESB Flow:

For Synchronous Flows it does suffice to use only Jmeter for loading the messages and capturing the metrics. Said that let’s create a test plan to test the webservice (Synchronous flow) in ESB. Rename this Test Plan node as WebserviceTest.

 

Follow below Instructions to set the test plan for WebserviceTest.

Configure Jmeter:

Add Thread Group: Add one Thread Group, which is placeholder for all other elements like Samplers, Controllers, and Listeners. Right click on WebserviceTest(our Test Plan) > Add > Threads(Users) > Thread Group. Thread Group will get added under the Test Plan (WebserviceTest) node.

As shown below the highlighted one is the thread plan. Make the changes to the thread properties to change the number of threads and then change the Rampup period,loop count  accordingly

ADD SAMPLER: To make the webservice call from Jmeter use SOAP/XML Sampler .So, Now that we have defined Threads (Concurrent Users), it is time to define the tasks that they will be performing. We will add SOAP/XML-RPC Request element. Click your right mouse button to get the Add menu, and then select Add > Sampler > SOAP/XML-RPC Request. Then, select the SOAP/XML-RPC Request element in the tree and edit the following properties as in the image below:

The following details are entered in this element:

Name: SOAP/XML-RPC Request

URL: http://localhost:7080/URI

Soap/XML-RPC Data: Enter the Soap Request message

Add Listener: The final element you need to add to your Test Plan is a Listener. This element is responsible for storing all of the results of your HTTP requests in a file and presenting a visual model of the data.

Select the Thread group element and add a View Results Tree listener (Add > Listener > View Results Tree).

RUN THE TEST PLAN: Now save the above test plan as test_webservice.jmx. Execute this test plan using Run > Start option.

VIEW OUTPUT: The following output can be seen in the listener. This confirms the webservice call is successful.

Performance Metrics: To get the actual performance metrics we need to add one more listener called ‘Summary Report’.

Select the Thread group element and add a Summary Report listener (Add > Listener > Summary Report). As a part of Summary report you can see that Throughput, number of messages (Samples), Error percentage.

Asynchronous ESB Flow:

For Asynchronous flows to capture the Performance metrics is challenging when compared to synchronous flows. To complete the life cycle of a message sometimes asynchronous application may involve multiple message flows. So, to gather performance metrics becomes challenging. To achieve this we use SupportPac IS03(Message Flow Statistics Visualiser) along with Jmeter .IS03 SupportPac which relies on the accounting and statistics facility of Message broker  has capabilities to see the real time and historic statistics data in tables, along with the capability to export all recorded data to CSV to enable custom user processing. Before we further proceed towards the testplan for performing the performance test we need to configure the Jmeter and Message Flow Statistics Visualiser with Message Broker.

Configure Jmeter:

For Jmeter the configuration is almost same as explained in synchronous flow except the sampler which depends on the connectivity protocol of the asynchronous application. For our exercise let’s consider the MQ protocol. In Jmeter to connect to queue manager we need to use JMS Point-to-Point sampler as shown in fig.

The following property changes are made to the JMS Point-to-Point sampler element:

Property	Value	Description
QueueuConnectionFactory	ConnectionFactory	This is the JNDI entry for the Connection Factory Defined within queue manager
JNDI Name Request Queue	Q.REQ	The JNDI name for JMeter to make the connection between the connection factory and queue.
JNDI Name Receive Queue	Q.REQ	The JNDI name for JMeter to make the connection between the connection factory and queue. We are using the same queue for response.
Communication Style	Request Response	This means that you need at least a service running outside of JMeter and that will respond to the requests. This service must listen to the Request Queue and send messages to the queue referenced by the message.getJMSReplyTo()
Use Request message ID	checked	You can leave JMeter to use the message ID Request (deposit) to the correlation between the incoming message and recovered.
Use Response message ID	checked	You can leave JMeter use the message identifier Response (recovery) for the correlation between the incoming message and recovered.
Time(milliseconds)	2000	This timeout is used when the message is received by JMeter if nothing is recovered in time (here 2 sec), then the item will be marked in error.
Content	Testing point to point	This is just the content of the message.
InitialContextFactory	com.sun.jndi.fscontext . RefFSContextFactory	The standard InitialContextFactory for MQ
Provider URL	file:C:/DEV_JNDI-Directory	JNDI file location

NOTE: for our test use communication style property as ‘Request only’ as we are going to use Jmeter only to load the messages for asynchronous performance testing.

The screen shot below shows above configurations:

Once Configuring sampler, create listener and save the test plan as guided in synchronous flow section.

Configure IS03 SupportPac:

Along with Jmeter we need to Configure SupportPac to retrieve metrics. Please follow below instructions to complete the IS03 Configuration setup.

1) Loading in Message Flows and Sub-flows

IS03 requires you to load in Message Flows before it is able to display them. You do this by pointing it at

their msgflow files. Perform the following steps to load in Message Flow files:

1. Select the add message flows button on the Config tab.
2. Select the parent directory where the msgflow files reside. This is likely to be the message flow project directory where Message Broker Toolkit stores the files.
3. IS03 will detect all the msgflow files within this parent directory and will prompt you with a dialogue (Figure 3.2) allowing you to load one or more of each of the flows. You will need to load in the correct number of each msgflow file. For example, if you have a simple flow which has no subflows, simply select ‘1’ next to the msgflow file. If you have a more complex flow e.g. a main flow, mainflow.msgflow , which uses two instances of the subflow tracesubflow.msgflow and one instance of the subflow errorhandler.msgflow then you would select 1 x mainflow.msgflow, 2 x tracesubflow.msgflow, 1 x

errorhandler.msgflow.

4. Select Submit and this will load each flow into a separate tab in the IS03 GUI.

Figure 3.2 – Load flows dialogue

After loading in a flow, you can view it by selecting its tab along the top of the GUI. Note that the layout of the nodes is based on the layout of the nodes in the WebSphere Message Broker Toolkit, so the nodes may need to be dragged around in the IS03 GUI for it to look correct.

2) Configuring which Statistics to graph

IS03 allows you to configure which statistics it will graph. These settings can be modified at any time.

The Config tab allows you to configure which statistics are displayed on each of the three graph types

(Message Flow Statistics, Node Statistics, Thread Statistics). To show or hide a particular statistic, simply

select or deselect the ‘selected to graph’ checkbox (Figure 3.3). The color of line a particular statistic should use can also be modified by clicking on the coloured region and selecting a new color.

Figure 3.3 – Selecting which stats to display

3) Starting statistics capture

Before you start statistics capture, ensure you have specified the ‘General config’ options correctly, as

specified in the ‘Setting Up IS03 SupportPac’ section of this document. To start statistics collection

simply click the Start stats collection button. The connection status field should go green and indicate that IS03 is successfully connected to the Queue Manager. If it goes red, indicating an error connecting, recheck your connection settings and retry.

4) Viewing statistics data

After statistics collection has successfully begun, data points will start being displayed in the node graphs. A new data point will appear each time that Message Broker publishes statistics data (i.e. every 20 seconds for Snapshot statistics). If your flow uses subflows, the statistics data for the subflow will be displayed on the subflow’s tab.

Figure 4.1 gives an overview of the GUI when a message flow tab is selected. Each of the highlighted parts of the diagram are explained in more detail below.

5) Exporting statistics data to CSV

IS03 is able to export all the statistics data which it has collected into a CSV format. This is done via the

‘Export options’ area on the Config tab (Figure 5.1). The interface gives you a configurable set of options to allow you to export exactly the statistics you are interested in.

Figure 5.1 – Export to CSV options

The CSV data is exported in a self-documenting format whereby the first row of the data defines the datafields, and the subsequent rows contain the data itself.

6) Resetting all statistics data

Select the ‘Reset all data’ button on the Config tab to clear all graphs. Note that after resetting the data, it is irretrievably lost and can no longer be exported.

What’s next?

If you’re still using WebSphere Message Broker, it might be time to think about upgrading your ESB. Whether you’re using an unsupported version of WMB or want the features of the newest IIB release, use our best practices compiled over the course of countless migrations to ease the process and maximize your IBM investment.