ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Performance Monitoring » Value of XQTIME doesn't make sense

Post new topic  Reply to topic
 Value of XQTIME doesn't make sense « View previous topic :: View next topic » 
Author Message
krypton
PostPosted: Wed Jun 12, 2019 4:06 am    Post subject: Value of XQTIME doesn't make sense Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Wed Jun 12, 2019 5:58 am    Post subject: Re: Value of XQTIME doesn't make sense Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
krypton
PostPosted: Wed Jun 12, 2019 6:13 am    Post subject: Re: Value of XQTIME doesn't make sense Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Wed Jun 12, 2019 6:18 am    Post subject: Re: Value of XQTIME doesn't make sense Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
krypton
PostPosted: Wed Jun 12, 2019 6:43 am    Post subject: Re: Value of XQTIME doesn't make sense Reply with quote

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
View user's profile Send private message
gbaddeley
PostPosted: Wed Jun 12, 2019 5:25 pm    Post subject: Re: Value of XQTIME doesn't make sense Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
krypton
PostPosted: Thu Jun 13, 2019 3:01 am    Post subject: Re: Value of XQTIME doesn't make sense Reply with quote

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
View user's profile Send private message
gbaddeley
PostPosted: Thu Jun 13, 2019 6:32 pm    Post subject: Re: Value of XQTIME doesn't make sense Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
bruce2359
PostPosted: Fri Jun 14, 2019 3:32 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
hughson
PostPosted: Wed Jul 03, 2019 3:27 pm    Post subject: Re: Value of XQTIME doesn't make sense Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Performance Monitoring » Value of XQTIME doesn't make sense
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.