Posted by: Rich Cumbers | August 20, 2009

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

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: