| Author |
Message
|
| klobubj |
 Posted: Tue Oct 09, 2007 10:15 am Post subject: MQ Performance tracing |
 |
|
Newbie
Joined: 18 May 2007
Posts: 4
Location: Pittsburgh Pa
|
| We have established MQ intercommunication with an external partner and are being asked to evaluate some of the performance lag between sites. Are there any tools or techniques that can help me evaluate the put times in the transmission queues as messages hop through our configuration of remote definitions to the ultimate local definition? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Oct 09, 2007 1:59 pm Post subject: Re: MQ Performance tracing |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| klobubj wrote: |
| We have established MQ intercommunication with an external partner and are being asked to evaluate some of the performance lag between sites. Are there any tools or techniques that can help me evaluate the put times in the transmission queues as messages hop through our configuration of remote definitions to the ultimate local definition? |
With no network latency and throughput monitoring between both sites you're SOL... 
You can check the timestamp on the message when you receive it. Remember it is UTC and you cannot tell much.
A good monitoring software may tell you what the average time on queue of the message was...
Truth be told this is usually dependant on
- put time
- Lag between put and commit (UOW processing)
- lag time to start the channel (when triggered)
- Network transmission time
- clock discrepancy between the sender and receiver boxes
- lag time to receive the message...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JuulV |
| Posted: Wed Oct 10, 2007 12:59 am Post subject: |
|
|
Apprentice
Joined: 05 Sep 2007
Posts: 28
Location: Belgium
|
Hi klobubj,
If you want to to trace "message latency" in real time, I think about the only way to do this is to use an API Exit that writes some key elements from the messages of interest (including the actual time that the PUTs and GETs were intercepted) to a shared file or DB, and have some tool to query this file/DB...
If you want to analyse this "after the fact", the WMQ Recovery logs can be used, but only if the messages are persistent (nonpersistent messages leave no trace behind in MQ, so these can only be tracked in real time)...
If you do some googling you might find one or two commerial tools out there that can assist you with either approach.
_________________
Juul Vanparijs
Senior Developer
Cressida Technology Ltd |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Oct 10, 2007 1:40 am Post subject: Re: MQ Performance tracing |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| klobubj wrote: |
| being asked to evaluate some of the performance lag between sites. |
So someone has already measured the time taken, and it's too long? Please give us an idea of the numbers involved here. |
|
| Back to top |
|
|
| markt |
| Posted: Wed Oct 10, 2007 3:20 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
|
| Back to top |
|
|
| klobubj |
| Posted: Wed Oct 10, 2007 4:03 am Post subject: |
|
|
Newbie
Joined: 18 May 2007
Posts: 4
Location: Pittsburgh Pa
|
Statistically speaking the mode is around 20 seconds from a database write on their side to the putdatetime on our local queue. They are using a third party product to capture changes on a database and put to a remote definition on thier side. They're telling us that constitutes 13 of the 20 seconds. That first leg seems terrible to me and has generated the scrutany on whole.
So, the leaves us with about 7 seconds to evaluate from thier remote definition to a remote definition on our side where we abstact some of the security and then the final hop to a local definition.
While I recognize clock drift is a consideration if it's off it should be pretty consistantly off minimizing that concern on whole.
We don't see much difference between the first message and one say a minute later so channel initates can't be that bad.
I have little to benchmark against so I'm open to any impressions. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 10, 2007 4:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
markt's excellent (as always) suggestion of dspmqrte only works if you're on v6, which OF COURSE you are.
It will give you lots of excellent information about how the message moves through the system, at each stop.
Other than that, you are stuck with trying to read between the lines of RESET Q STATISTICS.
Most likely candidate for any performance impact is going to be the oldest machine/ oldest version of qmgr in the chain, though. So if you know there's a backlevel qmgr in the mix...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Oct 10, 2007 4:34 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
Two ideas:
1. pay a LOT of attention to clock skew. This must be eliminated early, and could save you a lot of wasted effort.
2. take care to lay out on paper everything that happens in that 7 seconds. Discover what time each thing takes. Something may take 6.5 seconds and everything else takes 0.5. So focus on the thing that takes 6.5 seconds. Repeat this process until you find something that looks like it's taking longer than you think is right.
In order to support (2) investigate opportunities to trace what is going on. MQ can help here with its trace facility. Say "strmqtrc -m qmgrname -t api" and this will give you trace files in /var/mqm/trace (you have to run them through dspmqtrc to read them) which shows all MQI calls made on the queue manager, and the times they entered, and the times they completed.
Hope this helps |
|
| Back to top |
|
|
|
|
