There are a lot of variables involved with performance tuning IBM MQ.
What version of LISA are you on? DevTest 8.3 (devtest server is running on redhat and client is on windows 2008)
Are you using the new IBM MQ Native protocol, or the old IBM MQ Series protocol? I am using 'Native Client' i.e., 'IBM MQ Series (Deprecated) 'and VSM is created using both RR pairs & recording and then merged. mostly RR pair transaction are maximum. no think time set for any of the transaction. At this moment we dont have plan to change to new MQ series but yes eventually we do it.. and I hope using the protocol does not affect the performance..
Are there multiple request queues? yes three request queues & only one response queue.. all the three requests , responses will be put it into same response queue. the soap service will internally make call to these three request queue one after the other based on condition and responses will be received on same response queue.
Are there multiple response messages/queues? answered above.. response queue is one.. but messages received every time is different.
Is the response queue always the same, or are there temporary queues involved? same .. no temporary queues used in our case.. all queues are running on IBM MQ 7.1 (in our case only one response queue.. that we call as LISA.REPLY )
What's the average size of the request and response bodies? it is simple payload.. payload size is 200 to 300 lines for response.. 100 to 150 lines for request.
What data protocols are you using and how many arguments are there?
XML Data Protocal and Generic xml payload parser .. number of args in payload parser are around 30. But the reason it is 30 args because we have created individual mq call separately and merge the VSI and VSM args .. so it is growing in number of args.. but the request should always filters for arguments it needs and send the request to VSI image selection step ... in that way we hardly use 8 to 12 args for request matching in VSI.
Have you made any changes to the stock generated VSM? not much.. but yes there are two more steps added one is script step which is after 'MQ {vse.publisher} publish' step, this is very simple script to capture msg id & correlation id and followed by this step, there is another step which just writes these details file using 'write to delimited file'
Have you looked at the 'share sessions' checkbox (IBM MQ Series) or Run time Scope (IBM MQ Native) settings? I am not aware of this.. but I am using default as value for most of the properties in VSM & VSI step, well, there are some properties which needs to be changed as per our environment so those are changed and functionally it works fine when we use it for functional testing purpose.
below is the property details from VSI response - metadata
msg.applicationIdData
msg.applicationOriginData
msg.backoutCount 0
msg.characterSet 819
msg.encoding 546
msg.expiry -1
msg.feedback 0
msg.format MQSTR
msg.getVersion 2
msg.messageFlags 0
msg.messageSequenceNumber 1
msg.messageType 8
msg.offset 0
msg.originalLength -1
msg.persistence 0
msg.priority 0
msg.putApplicationName TSYS.Req
msg.putApplicationType 6
msg.replyToQueueManagerName TSYS.ST1
msg.replyToQueueName
msg.report 0
msg.userId mqm
msg.accountingToken 0000000000000000000000000000000000000000000000000000000000000000
msg.correlationId 414d51205379735465737431202020202aa09f5502a71820
msg.groupId 000000000000000000000000000000000000000000000000
msg.messageId 414d5120545359532e535431202020202ca09f55026f0d20
msg.putDateTime 1437484367460
recorded_raw_response_bytes PD94bWwgdmVyc2lvbj0iMS4wIj8+PHNvYXA6RW52ZWxvcGUgeG1sbnM6c29hcD0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHhtbG5zOnhza
dest.ccid
dest.channel LISA.CLIENT.01.01
dest.connectionMode Native Client
dest.destination LISA.REPLY
dest.destinationType Queue - ASYNC
dest.host MQ Server host
dest.overrideQueueManager
dest.password
dest.port 60100
dest.queueManager SysTest1
dest.receiveExit
dest.securityExit
dest.sendExit
dest.tempQueueModel
dest.isTemp false
dest.user mqm
dest.requestDestination false
dest.useCorrelationID false
dest.argumentsAll false
dest.argumentsProperties false
dest.argumentsCorrelationId false
disregardReplyTo false
mq.dest.env.Use Non-Destructive GETs false
mq.dest.env.Local Address Property default
mq.dest.env.connectOptions default
mq.dest.env.ConnTag Property default
mq.dest.env.Header Compression Property default
mq.dest.env.Message Compression Property default
mq.dest.env.SSL CertStores default
mq.dest.env.SSL Cipher Suite SSL_RSA_WITH_RC4_128_MD5
mq.dest.env.SSL Fips Required default
mq.dest.env.SSL Peer Name default
mq.dest.env.SSL Socket Factory default
Have you gone through the general recommendations for performance tuning VSE? Not sure about this.. if there is something like this , please share the wiki link, i ll have a look at it..
At what capacity are you running the VS? default.. 100%
What does the CPU usage on your VSE server look like? usage is not bad.. normal load and enough space & mem available on linux box which is hosting VSE server
What is the actual load, in transactions per second or maybe concurrent users, that you're trying to push through?
yeah, maximum is 5Vuser, laod is for 1 hour, tranx for a hour needed is 1250 .. every Vuser hits as soon as previous iteration ends..
[ when I put one Vuser or two vusers calls seems to be fine, and 99% calls are success, when I increase to 3 or more , then I start hitting these issues]