Performance Testing MQ with LoadRunner
21 October, 2008 – 5:04 pmThe wheel has turned full circle and I’m back in MQ land… So here is a a simple Java vuser harness which you can use in LoadRunner to put or get messages from Websphere MQ. This version doesn’t require any JNDI bindings (or access to JMS). Instead it just uses a standard server connection channel over TCP to get and put messages.
You will need to get the following jars from your Websphere MQ installation:
1. com.ibm.mq.jar
2. connector.jar
3. jta.jar
Make sure you include them in your run-time settings (F4) for your script:
PUT example
/* * LoadRunner Java script. (Build: 946) * * Script Description: simple test harness to PUT messages on a MQ queue * Author: Tim.Koopmans@90kts.com */ import lrapi.lr; import java.io.*; import java.util.*; import com.ibm.mq.*; public class Actions { private MQQueueManager myQueueManager; private MQPutMessageOptions myPutMsgOptions; private MQQueue myQueue; public int init() throws Throwable { try { MQEnvironment.hostname = "192.168.145.131"; MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY,MQC.TRANSPORT_MQSERIES_CLIENT); MQEnvironment.channel = "S_koops_5a7610a22"; MQEnvironment.port = 1414; MQEnvironment.CCSID = 437; myQueueManager = new MQQueueManager("QM_koops_5a7610a22"); int openOptions = MQC.MQOO_OUTPUT | MQC.MQOO_INQUIRE | MQC.MQOO_FAIL_IF_QUIESCING; myQueue = myQueueManager.accessQueue("default", openOptions, null, null, null); myPutMsgOptions = new MQPutMessageOptions(); myPutMsgOptions.options = MQC.MQPMO_NONE; } catch (Exception e) { System.out.println(e); } return 0; }//end of init public int action() throws Throwable { try { MQMessage myPutMessage = new MQMessage(); myPutMessage.clearMessage(); myPutMessage.persistence = MQC.MQPER_PERSISTENT; //myPutMessage.persistence = MQC.MQPER_NOT_PERSISTENT; myPutMessage.correlationId = MQC.MQCI_NONE; myPutMessage.messageId = MQC.MQMI_NONE; myPutMessage.writeString("<xml><data>foobar</data></xml>"); myQueue.put(myPutMessage, myPutMsgOptions); } catch (MQException e) { System.out.println(e); } return 0; }//end of action public int end() throws Throwable { try { myQueue.close(); myQueueManager.disconnect(); } catch (Exception e ) { System.out.println(e); } return 0; }//end of end }
GET example
I’ve included a private method which decodes the hex string (for the msgID) into ascii. You can also get creative here. In previous test efforts I’ve embedded a date time string in the user data of the request message, then extracted and got the difference from the MQMD header on the reply queue. In other words, elapsed time between request and response. I’m keeping it simple for the example though …
/* * LoadRunner Java script. (Build: 946) * * Script Description: simple test harness to GET messages on a MQ queue * Author: Tim.Koopmans@90kts.com */ import lrapi.lr; import java.io.*; import java.util.*; import com.ibm.mq.*; public class Actions { private MQQueueManager myQueueManager; private MQPutMessageOptions myPutMsgOptions; private MQQueue myQueue; public int init() throws Throwable { try { MQEnvironment.hostname = "192.168.145.131"; MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY,MQC.TRANSPORT_MQSERIES_CLIENT); MQEnvironment.channel = "S_koops_5a7610a22"; MQEnvironment.port = 1414; MQEnvironment.CCSID = 437; myQueueManager = new MQQueueManager("QM_koops_5a7610a22"); int openOptions = MQC.MQOO_INPUT_SHARED | MQC.MQOO_INQUIRE | MQC.MQOO_FAIL_IF_QUIESCING; myQueue = myQueueManager.accessQueue("default", openOptions); } catch (Exception e) { System.out.println(e); } return 0; }//end of init public int action() throws Throwable { try { MQMessage myGetMessage = new MQMessage(); myQueue.get(myGetMessage); System.out.println("MSG ID: \t"+dumpHexId(myGetMessage.messageId)); System.out.println("CORREL ID: \t"+dumpHexId(myGetMessage.correlationId)); System.out.println("MSG LENGTH:\t"+myGetMessage.getMessageLength()+" bytes"); System.out.println("MSG CONTENT: "+myGetMessage.readLine()); } catch (MQException e) { System.out.println(e); } return 0; }//end of action public int end() throws Throwable { try { myQueue.close(); myQueueManager.disconnect(); } catch (Exception e ) { System.out.println(e); } return 0; }//end of end private static String dumpHexId(byte[] myId) { String hexAscii = ""; for (int i=0; i < myId.length;i++) { char b = (char)(myId[i] & 0xFF); if (b < 0x10) { hexAscii = hexAscii + "0"; } hexAscii = hexAscii + (String)(Integer.toHexString(b)).toUpperCase(); } return hexAscii; }//end of dumpHexId }
5 Responses to “Performance Testing MQ with LoadRunner”
I am doing similar type of script in LR and it complies but do not execute.. getting this error.
16/11/2008 15:46:32 Error (-104998): RTC Client Error: Failed to get PT instance of RTC Client.
Just wondering if you got this.. Am i missing something really simple?
please let me know if you have any ideas
By pborse on Nov 19, 2008
Are there any errors prior to this? Anymore error information?
By Tim on Nov 19, 2008
Nothing. I did get compile errors like this
Error: Compilation process failed. [MsgId: MERR-22997]
Warning: Extension java_int.dll reports error -1 on call to function ExtPerProcessInitialize [MsgId: MWAR-10485]
Error: Thread Context: Call to service of the driver failed, reason - thread context wasn’t initialized on this thread. [MsgId: MERR-10176]
but once compilation error was gone, I got this sinlge error in mrdv.log file. Vugen output do not show anything.
By pborse on Nov 20, 2008
you have mentioned the classpath for jar file.. is it mandatory to have jar files in Classes directory under Mercury/LoadRuner
By pborse on Nov 20, 2008
It is not mandatory to have jar files in the the mercury classes directory. They can be anywhere on your system, provided you point to them in your runtime settings.
The fact that it’s compiling does not indicate a classpath problem. I would be more suspect of the versions of jars you are using against your target MQ installation. The example code given above was developed on MQ version 7.0.
Are you able to step through your code (F10) to see which line of code it is failing on? Vugen should be giving you more information than what you’ve reported…
By Tim on Nov 22, 2008