WebSphere MQ Performance – Hints and Tips

A long time ago I worked for the MQ Performance team, my current role is still loosely linked to that team as I am working on the performance for WebSphere MQ FTE. Recently I was asked to help a customer improve the performance figures that they were seeing from a JMS application. The application in question was actually the JMS Performance Harness, which can be found on Alphaworks. Many of the suggestions we made can be found in the myriad of performance reports that MQ delivers as Performance SupportPacs. These are delivered as PDFs, and as far as I know are not indexed by Google, which means that searching for information on MQ performance will not always give you the help that you were looking for. So I decided to compile the following hints and tips that you should use to improve performance.

Disclaimer: This post not sanctioned by IBM, and I am not copying information from the Performance reports verbatim. The following hints and tips are designed to improve the performance of your applications, when making changes to your environment you should ensure that the changes do not have unwanted side effects. Myself, or IBM, are not responsible for loss of data etc etc when using this information.

1. Use non-persistent messages where possible. Using persistent messages will require MQ to write the data to disk, which can be a performance bottleneck.
2. If you need to use persistent messages, ensure that you have are either using a separate disk for your MQ log files, or in an optimal scenario are using battery backed cached disks, for example a SAN.
3. Even if you are using non-persistent messages, the per queue buffer size might mean that MQ writes the non-persistent messages to disk. To avoid this you should set the DefaultQBufferSize and DefaultPQBufferSize for your queue manager to larger values. The default is 256kb
4. If you are using Channels, you can set the BindType to be FASTPATH. This will effectively reduce the CPU usage on the server, but it does mean that custom UserExits that are poorly written will not only crash your channel, but your queue manager too
5. MQ Version 7.0 introduced a new channel property called sharecnv. This property defines how many threads can use a single socket (the default value is 10). Setting this value to 1 may improve performance by limiting a single thread per socket.
6. JVM heap size is also important. Ideally you want to limit the number of times that the Garbage Collector is called. MP07 recommends that optimal GC interval is around 1-2 seconds.

The above points are by no means exhaustive. They are meant to stimulate MQ users into thinking a little more about getting the most out of the Queue Managers, and their applications.

MQ put a lot of time into developing Performance Reports, and it would be remiss of me to not mention them in this post. For each performance report there is a section that discusses performance for the platform (with the exception of the JMS report that is platform agnostic). The above points should be used in conjunction with the relevant report. The following is a list of links to the most recent reports for MQ Version 7:

• MP07 – MQ Version 7 JMS Performance Report
• MP6N – MQ Version 7 AIX Performance Report
• MP6P – MQ Version 7 Solaris Performance Report
• MP7I – MQ Version 7 Windows Performance Report
• MP6O – MQ Version 7 HP-UX Performance Report
• MPL5 – MQ Version 7 Linux Performance Report
• MPL6 – MQ Version 7 Linux (zSeries) Performance Report

Installing and Configuring SupportPac FA01

I recently posted about my first WebSphere SupportPac (FA01). The SupportPac basically allows your FTE network to be defined within WSRR using custom models. Although there is a pdf detailing install/setup contained in the download for FA01 I thought it would be useful to document here the steps required to install and configure the plugin. This information is for Version 1.0 of the plugin. Future versions may require different steps.

Software in use for this blog post
WSRR 6.3 using DB2 for its database
WMQ FTE 7.0.1

Installing the Plugin
All the following steps take place using the Configuration Perspective of the WSRR web application.

First install the plugin jar file, this is performed under the “Active Profile -> Plugin JARs” section. Click “Load JAR Plug-in”, browse your local filesystem to find the FA01 jar, call it anything you like – preferably something related to FA01, or WMQFTE. Now that we have loaded the JAR into WSRR’s classpath, we can now load the model and setup the ServiceDiscovery configuration.

In order to create the required objects in WSRR we need to pass in the OWL file which defines the objects in use by the plugin. The fte_model.owl can be found in the zip file under the folder called models. Navigate to “Active Profile -> Classification Systems”. Click “Load Classification System” and using Browse locate the fte_model.owl file. You should then see WebSphere MQ FTE Entities in the list of Classifications:

WSRR Classifications

WSRR now needs to now how to run the plugin. This is done using the “Active Profile -> Service Discovery”. Clicking on the ServiceDiscoveryConfiguration link will take you to an xml editor in which you can setup FA01. Look at this xml file (WordPress don’t allow txt files, so you have it as a .doc :S), you need to paste the contents of that doc into the xml editor, make sure you paste inside the tag at the bottom of the editor. You need to change the qmgr/host/port/channel values to reflect your coordination queue manager settings. Click OK to save this configuration.

Finally to enable regular running of the plugin we need to configure the scheduler. This can be found again using the menu option “Active profile -> Scheduler”. You should see the ServiceDiscoveryScheduler, which when clicked will again give you an editor with some xml. You need to add the xml from this Scheduler Config document. Change the intervalGranularity and interval values to suit your needs. Check the WSRR Infocenter for allowed values. Once you save this the Scheduler should run your plugin, and the FTE Concepts should start to appear in the relevant Perspective.

If you experience problems with the ServiceDiscovery Plugin, check your WSRR SystemOut and SystemErr logs, as the plugin will output information that will help to diagnose the problem

MS0T (Standalone MQ Explorer) & WebSphere MQ FTE

Recently IBM announced a SupportPac for WebSphere MQ for the Eclipse based WMQ Explorer. Called MS0T it is classified as a category 3 SupportPac and can be downloaded from the MS0T page.

One outcome of this Standalone edition of the WMQ Explorer is that you now no longer need to use the full WebSphere MQ installer and can just have the Explorer without the other parts of the product. This is pretty neat when you also want to administer your WebSphere MQ File Transfer Edition network on a remote machine without a full install. As of writing this post WMQ FTE does not support automatic installation of the File Transfer Plugin for the MQ Explorer and manual steps are required, and there are no plans to do so at present. Here are the manual steps required to make this work:

1. Install SupportPac MS0T (currently Windows only, support for Linux coming soon!)
2. Install the tools edition of WMQ FTE on the same machine as your Standalone Explorer is installed
3. Create a file called com.ibm.wmqfte.link in the Standalone Explorer eclipse/links folder that contains the following path=c:/your/wmqfte/tools/install/location
4. Start Explorer and you should see the familiar (if you have used it before) File Transfer Edition icons on the left hand side!

Please note: The slashes in the above property are forward slashes and must be forward slashes for this to work!

Let me know if you manage to get this working, or if not what went wrong!

Update: There is an official technote describing this exact scenario (written by using this post) http://www-01.ibm.com/support/docview.wss?uid=swg21394643. Thanks to Marcel Amrein for pointing this out.

IBM Managed File Transfer

A while ago on Twitter I had alluded to a new project that I as working on. I had managed to fly the WebSphere MQ nest, after helping to get version 7 out of the door. I was unable to talk about the project i was working on as IBM had not announced the product for all sorts of reasons, mostly ones that could land people in court. However I have now found some time to talk about what I will be up to for the next few months…

IBM recently announced that we are delivering a managed file transfer product, built on top of WebSphere MQ. (see product page here: http://www-306.ibm.com/software/integration/wmq/filetransfer/index.html). The long of the short is that we are delivering a product that will allow the end user to transfer files from A to B using WebSphere MQ as the transport. Some of the features currently in plan are things like scheduling and triggering.

We are working with 2 week iterations, with scrum meetings every day at 10 and yes we stand to try and keep it short, with each team member explaining what work they did yesterday, what work they are doing today, and anything that is blocking their progress. Currently there is a definite line between developers and testers, though not in the “Us vs Them” manner that sometimes exists. I am currently working as a developer, whilst also looking at the performance of our product and I am having a fantastic time. I have not had this much fun at work for ages, and it is showing in the time I am coming to work, and my general happiness around the house when home.

So far things are going very well, I am learning the code base, the team are delivering reguarly fortnightly code drops, which are ready for customer consumption.. On that note we are fully into our Early Access Program (EAP) and are deciding on a per iteration basis if the product should be given to customers. Watch this space for more information on my experience with Agile at IBM….