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

WebSphere MQ manual Registry entries

Just a quick post, as much for my benefit as anyone else’s! In running our automation it was required that when a new queue manager is created we edit the windows registry for that queue manager. Put simply, I did the following steps:

1. Created an XA Resource Manager using the MQ Explorer
2. Started my Queue Manager to make sure my changes worked (they did)
3. Stopped the Queue Manager
4. Exported the ‘XA Resource Manager’ key for my Queue Manager using regedit into a file
5. Deleted the ‘XA Resource Manager’ key from the registry.
6. Started my Queue Manager to make sure my deletion did not break anything
7. Stopped the Queue Manager
8. Imported the registry file using regedit /s registry.file
9. Tried to start the queue manager and got an error An expected stanza in the configuration data is missing or contains errors. and an fdc.

Turns out that all I need to do to get this to work is: amqmdain regsec and that will fix the registry permissions!

Infocenter page for amqmdain can be found here.

WebSphere MQ Java & Pub/Sub

Just a quick post about WebSphere MQ Java Pub/Sub functionality. I have need to write an application that uses the Base Java Classes for WebSphere MQ, making use of some Pub/Sub. There is a fair amount of information on the web on how to subscribe but no information on how to unsubscribve. To subscribe to a topic all you need to do once you have a MQQueueManager object is the following:

int options = CMQC.MQSO_CREATE | CMQC.MQSO_RESUME | CMQC.MQSO_DURABLE | CMQC.MQSO_FAIL_IF_QUIESCING;
MQTopic topic = qmgr.accessTopic("topicName", "topicObject", options, null, "DurabeIdentifier");

Now you have the MQTopic object you can get messages that are published to the topic “topicObject/topicName”. As I mentioned the reason for this post was the lack of any information on the web, including the WebSphere MQ Using Java V7 manual, and the WebSphere MQ V7 infocenter on how to unsubscribe from the topic. Well eventually I gave up on the web, and decided to look at the MQ Test material that we have here at Hursley. The following code will unsubscribe from the topic:

if (topic != null) {
if (topic.isSubscribed()) {
topic.getSubscriptionReference().setCloseOptions(CMQC.MQCO_REMOVE_SUB);
topic.getSubscriptionReference().close();
}
topic.setCloseOptions(CMQC.MQCO_DELETE);
topic.close();
}
That will check if your topic is not null, is subscribed and then set some options to ensure that the subscription is deleted. Job done and only an hour wasted searching the docs!

Update:You do not need to use topic.setCloseOptions(CMQC.MQCO_DELETE);. This would actually throw an MQRC_OPTION_NOT_VALID_FOR_TYPE (mqrc 2045) error!

Getting MQ and DB2 to talk on windows

Something had to force me from the blogging wilderness that I have been in since August of 2008. I’ll freely admit that I have neglected this blog, and intend to change. No really I do. It is not that I have not done anything interesting since August, since my last post we have released WebSphere MQ File Transfer Edition 7.0 and are now planning and developing for the future releases. My lack of posting has not been down to lack of time. In the time that it takes to complete a mission on Far Cry 2 (xbox360 naturally), or watch an episode of 24 (fantastic 7th season) I could have posted 2 or 3 articles. I think it comes down to not really finding my blogging voice, when reading my posts back to myself I always cringe and I think this is something I am just going to have to get used to. I think the term “strap on a pair” would best describe what I need to do.

Anyway on to my post. My current day job involved setting up a WebSphere MQ V7 Queue Manager to use DB2 as a Resource Manager for XA transactions. There are some docs on the infocenter for WMQ V7 here and here, but in following these I did not manage to get my queue manager talking and playing nice with a DB2 instance. There is also a rather well written DeveloperWorks article by Mr Ben Ritchie that has only one drawback and that is following the instructions for Windows does not make it all work nicely. So I thought I would explain my setup, and what I had to do to get it to work.

I have a Windows machine that has both WebSphere MQ V7 and DB2 9.5 installed. I want to use WebSphereMQ as the coordinator for my XA transactions. Nothing fancy, just a simple XA connections. The first thing to do is to create the queue manager that you are going to use. For the purposes of this article I shall call my queue manager DATABASE_QM. I also have a database called XADATABASE. My windows userid is fred and my password is pass1234.

The first thing the docs do not tell you is that you need to copy/move a file called jdbcdb2.dll from <WMQ Install Dir>/java/lib/jdbc/jdbcdb2.dll to <WMQ Install Dir>/exits. If you do not do this setup, then in the AMQERR**.log you will find errors telling you that MQ cannot find the jdbcdb2.dll file. A simple copy/move action and you are ready to move to the next step

All the configuration for the connection occurs in the database. Well everything except a single command. The configuration of the queue manager in Windows is best done using MQ Explorer. Access the queue manager properties by right clicking on the queue manager and selecting properties. Navigate to the “XA resource managers” menu option. Here is where you will add the details of the connection to the DB2 database. Click Add, and you will be presented with a dialog box. Here is where you Name your Resource Manager (anything you like), give it the name of the Switch File to use (jdbcdb2.dll), the XAOpenString which will consist of the following db=XADATABASE, userid=fred, pwd=pass1234, toc=p, tpm=mq; substitute your values for db, userid and pwd. Leave XACloseString blank, I won’t lie I have no idea what I would use this for, I just want to get MQ and DB2 talking! Finally ThreadOfControl is set to Process, which is good enough for me.

I mentioned the command to run on DB2, run the following: db2 UPDATE DBM CFG USING TP_MON_NAME MQ

Now aside from the action to move/copy jdbcdb2.dll to the exits folder you have followed what all the docs say you should do. The next step would be to stop the queue manager (if you have it running), and then start the queue manager. Except that does not work. You will get an error telling you that the queue manager could not connect to the Resource Manager. So here is the bit you really must do. The user id for which the default name is MUSR_MQADMIN that the ‘MQ Services’ process ‘amqmsrvn.exe’ is running as needs to belong to the group DB2USERS. The information about this can be found here. Once you add the user to the group, stop/start the MQ Services process, restart your queue manager and you should not have any error messages in your log files. At least it worked for me!

And so ends my self imposed blogging exile. Hope to post again soon, rather then 7 months down the line!