| Author |
Message
|
| Bosco |
 Posted: Tue Aug 31, 2004 10:49 pm Post subject: message travel time in a MQ queue |
 |
|
Novice
Joined: 30 Nov 2003
Posts: 17
|
Hi,
Is there a way to tell how long a message takes to travel in a MQ queue? For example, I send a message from a WBIMB broker on NT to an application on mainframe, I would like to gather some stats the message spends in the network before hitting the actually mainframe application.
Thanks
Bosco |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Sep 01, 2004 12:37 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| The message PUT time is in the header. |
|
| Back to top |
|
|
| kman |
| Posted: Wed Sep 01, 2004 6:53 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
| The message PUT time is the time it was PUT on the outputnode on NT. The mainframe program should run a check on this, against the system time ( as long as the clocks synch, and programs was in WAIT). Otherwise, time will differs a bit. |
|
| Back to top |
|
|
| kirani |
| Posted: Wed Sep 01, 2004 10:13 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Or write a channel exit to log timings for each transmitted message.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Sep 02, 2004 4:16 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Good luck trying to sync your clocks so that it accuratly captures time spent in flight. A Windows clock "ticks" only every tenth of a second, so you can never get your clocks synced closer than that. Since time spent between QMs is usually milliseconds, you will never have good #s.
If the QMs are on the same box, and they share a common clock, that is another story.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kman |
| Posted: Thu Sep 02, 2004 4:29 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
How about if you set the report option COA?
Let's say the Windows app send the message out, record the PUTTIME, then waits for the report coming back, then look up the time the report arrive on its reply-to-q, total those time divided by two would be around the time taken from windows to mainframe.
Only if you just wanted to know the time taken. You can't do this on all messages in production.. that would be something else 
Just a thought |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Sep 03, 2004 10:04 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| look up the time the report arrive on its reply-to-q |
And just how do you suggest we do this. 
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 03, 2004 7:07 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Quite a dangerous thought to think that we can just divide the round trip time in 2.
More accurate would be checking the put time on each message. This supposes that of course the clocks on both computers are synchronized... and that the processing time to create the acknowledgement message is negligible...
I have seen cases where from a to b the communication was lightning fast but from b to a it took forever... Go figure tcp/ip setups...
Enjoy
F.J. |
|
| Back to top |
|
|
| kman |
| Posted: Mon Sep 06, 2004 12:02 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
Hey.. I did not say the time divided by two would be the exact time. It would be around the time. And yes, once you receive the report, look it up against your clock, at least it will give an indication of the time travels..
Getting the time through the exits would be preferred. But I would rather check against the PUTTIME, it is easier to do. Just for indication of the time travels.. the message travelling time  |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Sep 14, 2004 4:11 pm Post subject: Re: message travel time in a MQ queue |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| Bosco wrote: |
Hi,
Is there a way to tell how long a message takes to travel in a MQ queue? For example, I send a message from a WBIMB broker on NT to an application on mainframe, I would like to gather some stats the message spends in the network before hitting the actually mainframe application.
Thanks
Bosco |
Sounds like some Project Manager or Application Lead is over thinking things. In my experience once the average message gets into the MQSeries environment it shoots through like a Bullet Train on a grease rail. I am talking mili-seconds. So exactly what are they asking you for? Twenty Seven 8x10 color glossy pictures with circles and arrows and a description on the back explaining what each one is to be used as evidence again you?
Lets see did it take .00019 seconds for the message to get from point A to point B or did it take .0002 seconds?
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| kman |
| Posted: Tue Sep 14, 2004 4:45 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
oooh You will be surprise what the PM would ask for.
I totally agree with the observation, and has experience such request before. In fact, not only I have to get the time for each message, I have to get the time for each type of transaction.
Then get the same under load. So they have that glossy charts to show. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Sep 16, 2004 9:11 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Transaction Vision from Bristol Technologies is excellent for this type of info. It tells you how long each MQ call took (among other things). And you can see exactly when the putting applications PUT ended and when the getting application get started.
MQ is screaming fast, so this times are most vlauable when the putter/getter is on the same system, since you avoid the whole time sync issue mentioned above. On UNIX and z/OS, the times reported are down to the micro second.
TV gave me a good appreciation on just how costly from a time perspective MQCONNs and MQOPENs are. PUTs, GETS and INQs take no time at all (milliseconds).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
