|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Value of XQTIME doesn't make sense |
« View previous topic :: View next topic » |
Author |
Message
|
krypton |
Posted: Wed Jun 12, 2019 4:06 am Post subject: Value of XQTIME doesn't make sense |
|
|
 Disciple
Joined: 14 Mar 2010 Posts: 186
|
We have just setup a new MQ interface, where application put Request Message in the MQ on UNIX and then the request message goes to Mainframe Queue Manager and from there it gets picked up and reply is put back in Remote Q on mainframe and via Sender channel messages sends back to UNIX.
We have just set MONCHL to HIGH on mainframe sender channel, but when I am monitoring the XQTIME and NETTIME it is not making sense.
Following are the values which I captured just now for XQTIME & NETTIME
XQTIME (12337, 11537) and NETTIME(76471, 77455)
now all our application throws error if they don't get response in 4 seconds.
but while looking at above XQTIME and NETTIME , these values are much higher than 4 seconds and no application has reported timeout error and they are getting response within 1 second.
So, I am wondering why the XQTIME and NETTIME has such high values? |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Jun 12, 2019 5:58 am Post subject: Re: Value of XQTIME doesn't make sense |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
krypton wrote: |
We have just setup a new MQ interface, where application put Request Message in the MQ on UNIX and then the request message goes to Mainframe Queue Manager and from there it gets picked up and reply is put back in Remote Q on mainframe and via Sender channel messages sends back to UNIX.
We have just set MONCHL to HIGH on mainframe sender channel, but when I am monitoring the XQTIME and NETTIME it is not making sense.
Following are the values which I captured just now for XQTIME & NETTIME
XQTIME (12337, 11537) and NETTIME(76471, 77455)
now all our application throws error if they don't get response in 4 seconds.
but while looking at above XQTIME and NETTIME , these values are much higher than 4 seconds and no application has reported timeout error and they are getting response within 1 second.
So, I am wondering why the XQTIME and NETTIME has such high values? |
What do you mean high values?? Isn't that 12 and 11 millisecs and 76 and 77 millisecs? I'd expect you'd have a hard time doing it in less time...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
krypton |
Posted: Wed Jun 12, 2019 6:13 am Post subject: Re: Value of XQTIME doesn't make sense |
|
|
 Disciple
Joined: 14 Mar 2010 Posts: 186
|
fjb_saper wrote: |
krypton wrote: |
We have just setup a new MQ interface, where application put Request Message in the MQ on UNIX and then the request message goes to Mainframe Queue Manager and from there it gets picked up and reply is put back in Remote Q on mainframe and via Sender channel messages sends back to UNIX.
We have just set MONCHL to HIGH on mainframe sender channel, but when I am monitoring the XQTIME and NETTIME it is not making sense.
Following are the values which I captured just now for XQTIME & NETTIME
XQTIME (12337, 11537) and NETTIME(76471, 77455)
now all our application throws error if they don't get response in 4 seconds.
but while looking at above XQTIME and NETTIME , these values are much higher than 4 seconds and no application has reported timeout error and they are getting response within 1 second.
So, I am wondering why the XQTIME and NETTIME has such high values? |
What do you mean high values?? Isn't that 12 and 11 millisecs and 76 and 77 millisecs? I'd expect you'd have a hard time doing it in less time...  |
Hi , you are right. I was thinking these values in millisecs, just saw that they are microseconds.
Also as per below definition in RED the time is measured after application put the message in XMITQ, then how come it can include any delay in the putting application (BLUE).
The time, in microseconds, that messages remained on the transmission queue before being retrieved. The time is measured from when the message is put onto the transmission queue until it is retrieved to be sent on the channel and, therefore, includes any interval caused by a delay in the putting application.
Two values are displayed:
A value based on recent activity over a short period.
A value based on activity over a longer period. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Jun 12, 2019 6:18 am Post subject: Re: Value of XQTIME doesn't make sense |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
krypton wrote: |
Hi , you are right. I was thinking these values in millisecs, just saw that they are microseconds.
Also as per below definition in RED the time is measured after application put the message in XMITQ, then how come it can include any delay in the putting application (BLUE).
The time, in microseconds, that messages remained on the transmission queue before being retrieved. The time is measured from when the message is put onto the transmission queue until it is retrieved to be sent on the channel and, therefore, includes any interval caused by a delay in the putting application.
Two values are displayed:
A value based on recent activity over a short period.
A value based on activity over a longer period. |
I figure the delay in the putting application (using syncpoint) would be the time between the put and the commit, during which the message is on the queue but not in a gettable state...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
krypton |
Posted: Wed Jun 12, 2019 6:43 am Post subject: Re: Value of XQTIME doesn't make sense |
|
|
 Disciple
Joined: 14 Mar 2010 Posts: 186
|
fjb_saper wrote: |
krypton wrote: |
Hi , you are right. I was thinking these values in millisecs, just saw that they are microseconds.
Also as per below definition in RED the time is measured after application put the message in XMITQ, then how come it can include any delay in the putting application (BLUE).
The time, in microseconds, that messages remained on the transmission queue before being retrieved. The time is measured from when the message is put onto the transmission queue until it is retrieved to be sent on the channel and, therefore, includes any interval caused by a delay in the putting application.
Two values are displayed:
A value based on recent activity over a short period.
A value based on activity over a longer period. |
I figure the delay in the putting application (using syncpoint) would be the time between the put and the commit, during which the message is on the queue but not in a gettable state...  |
makes sense, Thanks. |
|
Back to top |
|
 |
gbaddeley |
Posted: Wed Jun 12, 2019 5:25 pm Post subject: Re: Value of XQTIME doesn't make sense |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
krypton wrote: |
..now all our application throws error if they don't get response in 4 seconds. |
Wow, that's a low wait interval for a reply message over a distributed MQ design. Is there a specific business requirement for this 100% expected response time? You should allow for any unexpected / intermittent / transient delays in network, MQ or backend application / DB processing time. _________________ Glenn |
|
Back to top |
|
 |
krypton |
Posted: Thu Jun 13, 2019 3:01 am Post subject: Re: Value of XQTIME doesn't make sense |
|
|
 Disciple
Joined: 14 Mar 2010 Posts: 186
|
gbaddeley wrote: |
krypton wrote: |
..now all our application throws error if they don't get response in 4 seconds. |
Wow, that's a low wait interval for a reply message over a distributed MQ design. Is there a specific business requirement for this 100% expected response time? You should allow for any unexpected / intermittent / transient delays in network, MQ or backend application / DB processing time. |
Is 4 seconds are low, In my understanding it should be 1 second or less. Just take example of MQseries.net, whenver I clicked on any forum, I get the page in 1 seconds or less.
In current times, all end users wants to see results in 1 seconds or less. |
|
Back to top |
|
 |
gbaddeley |
Posted: Thu Jun 13, 2019 6:32 pm Post subject: Re: Value of XQTIME doesn't make sense |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
Quote: |
Is 4 seconds are low, In my understanding it should be 1 second or less. Just take example of MQseries.net, whenver I clicked on any forum, I get the page in 1 seconds or less.
In current times, all end users wants to see results in 1 seconds or less. |
True, in a normal situation. But if there is a slight delay, would you prefer the transaction to fail, or wait just a little bit longer to complete successfully? I prefer the latter.
It seems like you are using the MQGET wait interval as a hard limit on service time. It should be set to much greater than the longest service time that would typically be seen in daily operations, eg. double. 30 - 60 seconds is not unreasonable. If you need to meet service levels for response times, it should be managed in the front end app logic, not as a hard limit on the MQGET for reply message.
Referring to your example, I don't close the mqseries.net window because it didn't respond in 1 second. I wait. I would probably give up if the page failed to load after 30+ seconds, and then reload the page. _________________ Glenn |
|
Back to top |
|
 |
bruce2359 |
Posted: Fri Jun 14, 2019 3:32 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
What is the official Service Level Agreement for this application? SLA's usually anticipate some outlier response times.
An example SLA: 85% of all transactions complete in under 2 seconds, 95% complete in under 4 seconds, 99% in under 6 seconds.
If there is no negotiated SLA, users can complain about any/all response times.
Ok, you've identified a "symptom," a delay. What was the cause? If this is a new symptom, what has changed? _________________ 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 |
|
 |
hughson |
Posted: Wed Jul 03, 2019 3:27 pm Post subject: Re: Value of XQTIME doesn't make sense |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
krypton wrote: |
fjb_saper wrote: |
krypton wrote: |
We have just set MONCHL to HIGH on mainframe sender channel, but when I am monitoring the XQTIME and NETTIME it is not making sense.
Following are the values which I captured just now for XQTIME & NETTIME
XQTIME (12337, 11537) and NETTIME(76471, 77455)
now all our application throws error if they don't get response in 4 seconds.
but while looking at above XQTIME and NETTIME , these values are much higher than 4 seconds and no application has reported timeout error and they are getting response within 1 second.
So, I am wondering why the XQTIME and NETTIME has such high values? |
What do you mean high values?? Isn't that 12 and 11 millisecs and 76 and 77 millisecs? I'd expect you'd have a hard time doing it in less time...  |
Hi , you are right. I was thinking these values in millisecs, just saw that they are microseconds. |
I couldn't say anything at the time because we hadn't released the new version of MO71 that we were working on, but I think this might help?
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|