| Author |
Message
|
| KIT_INC |
 Posted: Fri May 27, 2011 7:48 am Post subject: Please help on how to read Queue Time |
 |
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
I am trying to understand what the QTIME value means when I display queue status. My MQ version is 7.0.1.5 on WIndows
The MQSC command reference manual says
"QTIME
Interval, in microseconds, between messages being put on the queue and
then being destructively read. The maximum displayable value is
999 999 999; if the interval exceeds this value, 999 999 999 is displayed.
The interval is measured from the time that the message is placed on the
queue until it is retrieved by an application and, therefore, includes any
interval caused by a delay in committing by the putting application.
Two values are displayed:
- A value based on recent activity over a short period of time.
- A value based on activity over a longer period of time."
My simple interpretation is the first queue time number is the interval in microsecond between the MQPUT and MQGET
Here is a test I did
I created a new queue called QTIME with
Default persistent = persistent
Queue monitoring = hight
Queue statistics = on
Queue accounting = on
Before I put any message to the QTIME, All these fields contains nothing
The Qstatus output (Using MQ Explorer) shows
Queue Time
Oldest Message age
Last Put date
Last Put time
Last Get date
Last Get time
I used RFHUTIL to do a put and a get (1 message) with almost no delay in between
The Qstatus output (Using MQ Explorer) shows
Queue Time 807852 807852
Oldest Message age
Last Put time 10:35:50
Last Get time 10:35:50
I can see that (Queue Time) the time between PUT and GET is 807852 micro seconds which is about 0.8 second.
I used RFHUTIL to do a 2 put and 1 get with almost no delay in between
The Qstatus output (Using MQ Explorer) shows
Queue Time 915740, 915740
Oldest Message age 2
Last Put time 10:36:48
Last Get time 10:36:48
I can see that (Queue Time) the time between PUT and GET is 915740 micro seconds which is about 0.9 second.
Because I have 1 message left behind on the queue. I see the value in Oldest Message age increasing.
** I have no problem up to this point. I start to get confused after this.**
I waited for about 2 minutes (I see Oldest Message age = 127), then I used RFHUTIL to do a get to remove the last message from the queue.
The Qstatus output (Using MQ Explorer) shows
Queue Time 43855178 43855178
Oldest Message age
Last Put time 10:36:48
Last Get time 10:38:57
In this case the time (Queue Time) between PUT and GET is 43855178 micro seconds which is about 43.8 second. But according to last put time and last get time, it should be 2 minutes.
I repeat the Test once more by doing 2 PUTs followed by 1 GET with a few seconds delay in between
The Qstatus output (Using MQ Explorer) shows
Queue Time 35092889 35092889
Oldest Message age (some value that I missed)
Last Put time 10:41:06
Last Get time 10:41:15
In this case the time (Queue Time) between PUT and GET is 35092889 micro seconds which is about 35 second. But according to last put time and last get time, it should only be 9 seconds
Because I have 1 message left behind on the queue. I see the value in Oldest Message age increasing.
I waited agin for about 2 minutes (Oldest Message age = 111), then GET the last message off the queue
The Qstatus output (Using MQ Explorer) shows
Queue Time 50927864 50927864
Oldest Message age
Last Put time 10:41:06
Last Get time 10:43:00
In this case the time (Queue Time) between PUT and GET is 50927864 micro seconds which is about 50 second. But according to last put time and last get time, it should be 114 seconds
Can some one help me to understand this? Is my interpretation of Queue Time wrong ? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri May 27, 2011 8:09 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Looking at your tests and experience could it be the time between last put and last get? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Fri May 27, 2011 8:23 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| Hi fjb_saper, sorry I do not understand your question. Are you saying that something could be wrong with the last put time and get time ? Those time seems to match up with my wait time and also the message age. It is the queue time that does not match with my test unless my interpretation of the manual is wrong. But the manual says QTIME si "Interval, in microseconds, between messages being put on the queue and then being destructively read". So should that be the last get time minus the last put time? |
|
| Back to top |
|
|
| dawerbuch |
| Posted: Tue Nov 15, 2011 1:36 pm Post subject: |
|
|
Novice
Joined: 16 May 2001
Posts: 20
Location: New York, NY
|
Hi KIT,
I would take your original post and
1) submit it mqseries listserv, see what you get from there.
2) consider opening a PMR with IBM to explain it for you.
if you do #2, please share the final answer with all of us.
Thanks,
Dave
_________________
-=--=--=--=--=--=--=--=--=--=--=--=-
David Awerbuch - IBM Certified MQSeries Specialist
WMQ Systems Administrator
Bloomberg LP
email: dawerbuch -at- bloomberg.com
email: david_awerbuch -at- yahoo.com
Tele: 1-212-617-6184 |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Nov 15, 2011 2:14 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you have a single message on the queue, then LastPut time is the time that that message was put to the queue.
If you have more than one message on the queue, then Last Put Time is the time that the newest message was put on the queue.
If you have zero messages on the queue, then Last Get Time is the time that the queue went from having one message to having zero messages.
If you have more than zero messages on the queue, then last Get Time is the time that the last MQGet destructively read a message.
QTime is essentially an average of the amount of time that each individual message spent sitting on the queue, between when it was PUT and when it was GET.
So if you put one message, wait one minute, put another message, and wait one minute, then Last Put time is one minute. And QTime should be one and a half minutes, because one message has been sitting for two minutes and one message has been sitting for one minute (1+2/2=1.5).
At least, that's how I interpret it.
Let us know if the PMR says differently! |
|
| Back to top |
|
|
| George Carey |
| Posted: Mon Nov 21, 2011 1:57 pm Post subject: Results on this |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Any definitive statement on Qtime interpretation, PMR or otherwise here ?
Another interested party in knowing as well ...
GTC
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Nov 22, 2011 2:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I by no means count as an authoritative source.
Some experimentation might yield some better ideas. |
|
| Back to top |
|
|
| markt |
| Posted: Tue Nov 22, 2011 4:47 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 504
|
From various bits of documentation:
| Code: |
|QTIME |An indicator value representing the interval between a |
| |messages being put on the queue and then being |
| |destructively read. The value is shown in microseconds |
| |formatted into a string of up to 9 digits. When the time |
| |exceeds what can be display in 9 digits (1000 seconds = 16 |
| |minutes) the value 999999999 will be displayed indicating |
| |overflow. |
| |This time is measured from the time the message is placed |
| |on to the queue until it is retrieved by an application, |
| |and therefore includes any interval caused by a delay in |
| |committing by the putting application. |
| |This will display 2 values |
| |. a short term indicator |
| |. and a long term indicator |
|
| Quote: |
The short term indicator is the first value in the pair and is calculated in a way such that more recent measurements are given a higher weighting and will have a greater effect on this value. This gives an indication of recent trend in measurements taken.
The long term indicator in the second value in the pair and is calculated in a way such that more recent measurements are not given such a high weighting. This gives an indication of the longer term activity on performance of a resource.
|
The precise definitions of "long" and "short" are not documented; they might change over time and by platform and the lengths cannot be modified by users. The indicators are not strict averages, to avoid maintaining too much history, but can be considered approximately an average. But as an order of magnitude, you can imagine them as being calculated from the most recent 10 or 100 operations.
QTime can only be calculated for messages that have been removed from the queue - messages that have not been read do not contribute to the calculations of these indicators. |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Oct 17, 2012 5:19 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| Quote: |
| ... and therefore includes any interval caused by a delay in committing by the putting application. |
Wouldn't it be much more useful if this was not a case? How can I determine how long does it take for a channel to commit when I see qtime rising, in order to establish that consumer application is not getting messages promptly as soon as they are available? xqtime from chstatus (or qtime of xmitq from qstatus) are contaminated by the same kind of logic, and even if they weren't (producer application commits promptly), I'm not sure how to take this into exact account to establish how much delay introduces channel, and how much consumer application. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 17, 2012 11:14 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
you are trying to solve 2 problems here.
Let the consuming application fend for itself. Any build up in it's input queue may or may not be a source of concern.
However any build up on the xmit queue is source of concern for you.
Go find the culprit and  them.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 17, 2012 1:36 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9400
Location: US: west coast, almost. Otherwise, enroute.
|
[quote="jcv"]
| Quote: |
| ... I'm not sure how to take this into exact account to establish how much delay introduce[d by the] channel ... |
I'm presuming that you have SENDER-RECEIVER channels between the two qmgrs, yes?
What are the batchsize and batchinterval attributes of the channels?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
