The 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:
Read More
This is a relatively new example of how to use JMeter with WebSphere MQ. This approach is a clever way of inserting messages into MQ using a JMS sampler (point to point) with a JNDI binding within MQ.
I had not heard of this approach before and am sure it will be useful in future, provided you have sufficient access to create the bindings in the first place.
Read More
Recently I have been trying to determine what the impact of using MQ message persistence is on disk subsystem performance. There is alot of literature from IBM recommending ideal configurations to support MQ persistence, so I won’t turn this into a post that recommends ideal settings. What I did want to achieve though, was to get a better understanding of how MQ interacts with the disk subsystem when using message persistence, so that I could plan for capacity and make better recommendations for tuning on a production SAN environment.
Read More
So I spent the best part of a day assisting our sys admin and developer resolve MQ errors that a COBOL client was throwing when opening more than one concurrent connection to a clustered queue manager.
Because the architecture had recently changed to a cluster, and my load harness was no longer getting the desired response times, we all went down the track of investigating issues with clustering as this was the new kid on the block. Whilst the developer and sys admin revealed many other interesting tid bits of information regarding correct configuration and the like, we still could not collectively resolve the problem: the COBOL code was throwing a 2195 reason code on multiple MQCONN calls to the queue manager.
Read More
Once again on the topic of performance testing Business Objects, when executing a benchmark for a web intelligence report with goal being to see how many concurrent users it could support, the following error mesage was being generated in the vuser log:
Connection failed. The server has reached the maximum number of simultaneous connections. (Error: RWI 00239) (Error: INF )
What to do?
Read More
