| Author |
Message
|
| Sam Uppu |
 Posted: Mon Jul 20, 2009 7:54 pm Post subject: amqsmon utility |
 |
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Hi Guys,
We are on MQ v7.0.0.1 and Solaris 10.
We are having a request/ reply scenario and using MQ clustering.
We are in performance test environment and the source and destination apps are able to produce their stats how much time they took to process the msgs and they are expecting to produce MQ stats which they think that MQ may be a bottleneck for the performance issues. I am not sure whether there are any tools which can provide such kind of information. The source app is sending 300 messages per second(each msg is of ~2KB). The test duration varies from 5 minute to 12 hours.
Right now I am using amqsmon utility to measure the "averageQueueTime" and "maxqueuedepth" parameteres of SYSTEM.CLUSTER.TRANSMIT.QUEUE to check whether is there any latency in MQ to transfer the data from one qmgr to the other. Sometimes the averagequeuetime is showing zero which concerns me as there should be some value when the test is under progress. and also the putcount is showing as zero on SCTQ.
Do you guys think amqsmon is a reliable utility to know the stats?.
Does anybody is using any other approach while dealing with MQ benchmarking tools.
Thanks. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Jul 20, 2009 10:25 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you set monitoring to low, you could look at msgage when doing a queue status. It will tell you the msg age (in seconds) of the oldest msg on the queue. You will need a good ntp synch for that to work right...
Interrogate at a suitable interval. It looks like this gets renewed when the transaction is complete (msgage =5 curdepth=0).
If you check this on an app input queue remember that it will also increase if the application is the bottle neck...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| vol |
| Posted: Tue Jul 21, 2009 1:49 am Post subject: |
|
|
Acolyte
Joined: 01 Feb 2009
Posts: 69
|
| Since this is a clustered setup easily the most likely cause of any bottleneck is network latency. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 21, 2009 2:33 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Non persistent messages put outside of syncpoint to a waiting getter (like a sending channel MCA) will be passed in memory. Bypassing the enque / deque counters.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Tue Jul 21, 2009 9:39 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| fjb_saper wrote: |
If you set monitoring to low, you could look at msgage when doing a queue status. It will tell you the msg age (in seconds) of the oldest msg on the queue. You will need a good ntp synch for that to work right...
Interrogate at a suitable interval. It looks like this gets renewed when the transaction is complete (msgage =5 curdepth=0).
If you check this on an app input queue remember that it will also increase if the application is the bottle neck...
Have fun |
I am also using the MONQ attribute turned on and set MEDIUM on the qmgr.
I see the lastput/get time and dates and also MSGAGE(0) and QTIME(0, 0) fields which are important to monitor. I think this information can also be getting thru amqsmon with the averagequeuetime and maxdepth fields of amqsmon output.
Which kind of tools are you guys using to measure the MQ stats or throughput?. IBM provided a good tool which can transport data but no track record how much time it took to process from one end to the other.
thanks for your thoughts. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jul 21, 2009 8:17 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Looks like you need a monitoring tool that will allow you to compute for you the enqueue rate and dequeue rate of the queue / channel/ etc...
You can then do your own calculations and draw your own conclusions.
And be aware that sometimes the bottle neck is not where is seems.
If your channel can send 8000 msg / min and you dump 10,000 msgs into the xmit queue in one go .... you make the math...
The question is really there why do you need to commit the 10,000 messages? Looks awfully like a batch... You should make sure that each msg is it's own transaction for online stuff. If batching maybe a lower size will go much better....
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
