| Author |
Message
|
| CSwords |
 Posted: Tue Feb 15, 2005 11:12 am Post subject: MQ PutDate and PutTime |
 |
|
Newbie
Joined: 15 Feb 2005
Posts: 1
|
BACKGROUND
-------------------
I am communicating with a vendor application which utilizes MQ messaging. To send data to the application, you "put" messages on a specific input queue and to receive responses, you "get" messages from a specific output queue.
I would like to determine message turnaround time - specifically how long it takes for the vendor application to process a message.
I can track the time I sent a message to the application (performed a "put") and received a message from the application (performed a "get"). However, if there is a buildup of messages on my end, the time I perform the "get" will reflect the time my application got around to reading the message - NOT the time the vendor application sent the message.
QUESTION
-------------
Is there a way to tell when the vendor application performed a "put"? I see in the MQMD, there are two fields called PUTDATE and PUTTIME.
1) Can I use these fields?
2) Are they set by MQ or the vendor application?
3) Are these fields always set or does the vendor application have to specify that they be used?
4) If the vendor application puts a message on a remote queue, will this time represent the time the message was put on the remote queue, transmit queue or received on my local queue?
Thank you for any insight into this matter! |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Feb 15, 2005 2:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| CSwords wrote: |
Is there a way to tell when the vendor application performed a "put"? I see in the MQMD, there are two fields called PUTDATE and PUTTIME.
1) Can I use these fields?
2) Are they set by MQ or the vendor application?
3) Are these fields always set or does the vendor application have to specify that they be used?
4) If the vendor application puts a message on a remote queue, will this time represent the time the message was put on the remote queue, transmit queue or received on my local queue?
|
1) Yes, but remember the date and time will be in string format and UTC time zone
2) By default I would say they are set by MQ. However in some cases you can have the application set them.
3) I believe they are always set. By default -- if empty and override flag not set -- the qmgr will set them.
4) It will represent the time the message was put on the remote queue/transmission queue (difference negligible). However the channel can be closed or having communication problems and you may receive the message way later if its been sitting in the xmitq for some time.
Enjoy  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 15, 2005 4:57 pm Post subject: Re: MQ PutDate and PutTime |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| CSwords wrote: |
However, if there is a buildup of messages on my end, the time I perform the "get" will reflect the time my application got around to reading the message - NOT the time the vendor application sent the message.
|
If this is the scenario you are in, then you shouldn't be worried about the vendor app, since your app is the bottleneck!
Once you get your app performing fast enough to keep the reply queue empty, then you can use the method of subtracting the MQPUT time of the request from the MQGET time of the reply. But even then you have variables that may exaggerate the amount of time you attribute to the vendor app.
An API exit that capture's the vendor's put and get time stamps is really the only way I know of that you can accomplish this with any certainty. Bristol Technologies Transaction Vision does it this way - I use it all the time to show apps which component is slow.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vijay Kumar P |
| Posted: Wed Feb 16, 2005 9:18 pm Post subject: PutDate & PutTime |
|
|
Novice
Joined: 24 Jan 2005
Posts: 10
|
Hi,
Actually to use PutDate & Putime field, you need to set the contexts and moreover the these fields display time in GMT, you need to explicitly convert it.
Regards,
Vijay. |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Thu Feb 17, 2005 1:23 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
You could also consider looking at the Expiry field, if a message is put with an expiry of 5 seconds and has 4.5 seconds when it arrives then it has been sitting on MQ queues for .5 seconds. Of course if it doesn't arrive at all is has been waiting far too long 
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Feb 17, 2005 4:12 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| bob_buxton wrote: |
| You could also consider looking at the Expiry field, if a message is put with an expiry of 5 seconds and has 4.5 seconds when it arrives then it has been sitting on MQ queues for .5 seconds. Of course if it doesn't arrive at all is has been waiting far too long |
that's assuming you know the original expiry was 5 seconds, could have been 10, 20, 30
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Feb 17, 2005 7:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
And it doesn't take into account how long the aother app held it. You put the message with an expiry of 5, the other app picks it up immediatly, it takes 1 day to process it, it puts it back to the reply queue with an expiry of 5, and then......
Or it puts it back with an expiry of 10, or 1000000......
Expiry cannot help here.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Fri Feb 18, 2005 2:23 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
I think it is a bit extreme to say Expiry is no help.
Yes it requires some knowledge of how the other application is handling expiry but even if you cant see the source code of the application you can examine the reply messages and see what is being returned. If it is always less than the expiry of the request message they are probably passing remaining expiry from the request message, if it is -1 they are using unlimited (and no useful information can be gained) otherwise you can probably round the expiry up to the nearest whole second or multiple of five seconds and assume that was the original expiry. Very few applications would choose 'odd' expiration values or change them for each message.
None of this is precise but a large difference in actual expiry time from the expected would indicate that the applications are not processing the queues fast enough whilst a small difference would indicate processing within the application as the source of delay in getting a response.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 18, 2005 10:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bob_buxton wrote: |
Very few applications would choose 'odd' expiration values or change them for each message.
|
Even fewer decrement the time they spend on the message from the incoming Exiry value. Most just copy the incoming Expiry value into the outgoing Expiry value.
The request gets picked up with a 9.9 second expiry.
The app takes 3 seconds to process the message.
The app puts the reply out with a 9.9 second expiry.
Using Expiry, it would seem the app took less then one tenth of a second to process.
The only time Expiry could be used with any value is if the replying app took the time to note how long it took from the MQGET of the reply to the MQPUT of the request, and it then decremented the Expiry by that amount, and the messages did not spend any time sitting in queues. But at that point, why not just have the replying app log those times?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Fri Feb 18, 2005 12:41 pm Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
| Quote: |
Most just copy the incoming Expiry value into the outgoing Expiry value.
...
Using Expiry, it would seem the app took less then one tenth of a second to process.
|
No it doesn't
You put the the message with 10 second expiry and 3.5 seconds later you get a reply message with expiry time 9.5 seconds
So you can tell that the application ran for 3 seconds and it was on queue for .5 second. Of course tenth second resolution is too crude for timing many applications.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 18, 2005 1:15 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
duh...my brain wasn't thinking of taking the extra step of doing that extra math on the receiving side.
Bob is right.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
