| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| RFE - Include total response time for MQI and Queue distribu |
« View previous topic :: View next topic » |
| Author |
Message
|
| tczielke |
 Posted: Tue Nov 13, 2012 6:08 am Post subject: RFE - Include total response time for MQI and Queue distribu |
 |
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Hello,
I have created an RFE for "Include total response time for MQI and Queue distributed count statistics". This extra statistical information will be very helpful for administrators who have to support MQ application incidents that involve performance, users who need to do performance analysis of distributed MQ, and other use cases as well.
Please vote for it, if you would find this MQ distributed enhancement beneficial.
RFE - http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=28409
To vote, locate the "RFE Actions" section on the right hand side of the screen and click the vote link.
Headline:
Include total response time for MQI and Queue distributed count statistics
Description:
Please enhance the WebSphere MQ distributed statistics to include a total response time for any relevant count that is collected for MQI or queue statistics. For the cases where a wait time is applicable (i.e. MQGET), include both the total response time and the time just spent in wait.
For example, for the following section of the queue statistics:
PutCount: [100, 100]
PutFailCount: 100
Put1Count: [100, 100]
Put1FailCount: 100
PutBytes: [1000, 1000]
GetCount: [100, 100]
GetBytes: [1000, 1000]
GetFailCount: 100
BrowseCount: [100, 100]
BrowseBytes: [1000, 1000]
BrowseFailCount: 100
I would like to see the following added. I will assume the following time is in milliseconds, but choose whatever is appropriate.
PutCount: [100, 100]
PutCountRespTime: [0.01, 0.01]
PutFailCount: 100
PutFailCountRespTime: 0.01
Put1Count: [100, 100]
Put1CountRespTime: [0.01, 0.01]
Put1FailCount: 100
Put1FailCountRespTime: 0.01
PutBytes: [1000, 1000]
GetCount: [100, 100]
GetCountRespTime: [0.01, 0.01]
GetCountRespWaitTime: [0.001, 0.001]
GetBytes: [1000, 1000]
GetFailCount: 100
GetFailCountRespTime: 0.01
GetFailCountRespWaitTime: 0.001
BrowseCount: [100, 100]
BrowseCountRespTime: [0.01, 0.01]
BrowseCountRespWaitTime: [0.001, 0.001]
BrowseBytes: [1000, 1000]
BrowseFailCount: 100
BrowseFailCountRespTime: 0.01
BrowseFailCountRespWaitTime: 0.001
Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Tue Nov 13, 2012 6:51 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
What do you mean by response time?
For example, are you looking for the the lag between issuing mqput and the receipt of the msg and r/c?
_________________
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 |
|
|
| tczielke |
| Posted: Tue Nov 13, 2012 7:28 am Post subject: More details about response time |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
For response time, I mean the time it took for the application to initiate a call and get a response back from MQ. So for example, the application makes an MQPUT at 11:05:002000 and gets a response back at 11:05:002100, so the response time for that MQPUT was 0.000100 seconds. For the calls that can have a wait time (like MQGET), there should be 2 response times reported. The total response time, and the time spent in wait. This will help to see how much "active" time was spent in MQ for the MQGET.
Thanks,
Tim |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Nov 13, 2012 10:30 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
"Get a response back" == reason code?
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Nov 13, 2012 11:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
He's basically asking for the same data that exists in an mq trace, where the mq trace logs the time that the function was invoked and the time that the function returns control back to the application.
So, yes, the amount of time it takes for MQPUT to populate the RC. |
|
| Back to top |
|
|
| tczielke |
| Posted: Tue Nov 13, 2012 11:52 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Yes. For the MQPUT example, the time it takes for the MQPUT call to begin and end. With MQI calls that can have a wait built into them like the MQGET example, the wait time should be reported as well, so you know how much time of the MQGET was just wait time.
So the gist of this is to get statistical performance data on how much time it is taking for the MQI calls to complete. This data can be very helpful for diagnosing problems.
For example, let's say someone is reporting MQ is slow every day around the noon time. If this statistical response time data existed, you could turn on queue statistics around the noont time and see that the non-persistent PUTs are being completed in milliseconds but the persistent PUTs are taking several minutes to complete. This would be a clue that the issue might be with I/O write delays to the log. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 13, 2012 11:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| tczielke wrote: |
Yes. For the MQPUT example, the time it takes for the MQPUT call to begin and end. With MQI calls that can have a wait built into them like the MQGET example, the wait time should be reported as well, so you know how much time of the MQGET was just wait time.
So the gist of this is to get statistical performance data on how much time it is taking for the MQI calls to complete. This data can be very helpful for diagnosing problems.
For example, let's say someone is reporting MQ is slow every day around the noon time. If this statistical response time data existed, you could turn on queue statistics around the noon time and see that the non-persistent PUTs are being completed in milliseconds but the persistent PUTs are taking several minutes to complete. This would be a clue that the issue might be with I/O write delays to the log. |
Would you not just turn trace on for a few mins while this happens and then analyse the trace? This could have multiple different reasons. Anyways a correct monitoring system OS wise should already tell you that you are having disk IO problems...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 14, 2012 4:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
| He's basically asking for the same data that exists in an mq trace .... |
He's basically asking for the same data available from z/OS SMF and RMF statistical and accounting records.
_________________
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 |
|
|
| tczielke |
| Posted: Wed Nov 14, 2012 5:37 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
For the comment about turning on the MQ trace and analyzing the data, I am currently doing this because this is my only recourse to get this data on the distributed environments. However, when you run a trace for 5-10 minutes and you are dealing with 100s - 1000s of MQI calls, this can become quite cumbersome to analyze this data. I have written a C program to pull some of this performance data out of the trace and summarize it, but writing this code has been very time intensive.
If IBM would provide this statistical response time data, it would be very helpful for me in handling Production support issues that involve distributed MQ, especially around performance. As one other person mentioned, z/OS is currently providing this data. So this would be getting the distributed MQ statistical data to be more robust like the z/OS statistical data.
Thanks,
Tim |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Nov 14, 2012 5:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What I was trying to say is that the pointer should be available to you before you even analyze the data. Analyzing the data should be a last resort.
I am sure you monitor zOS for memory usage, cpu usage, I/O, disk performance, etc... and that you look at this data when you run into problems.
The same way a unix or windows OS can be monitored for the same criteria.
You need access to that same data. Just request it.
A slow MQ disk write does not tell you whether the problem is with the IO to the disk, or the disk performance, or just any other component in between like Network bandwidth (SAN) (using regular pipe to SAN for SAN backup...), disk controller, etc... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed Nov 14, 2012 9:05 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
I do agree that there are other ways to diagnose a slow I/O disk issue other than these MQ response time statistical enhancements, but this data would still be helpful for this type of situation. This example notwithstanding, there are many other MQ production support issue examples where this respone time statistical data would be helpful. Bottom line is that the more data you have at your disposal, the better you can do your job.
Again, I find this type of MQI and queue resposne time statistical data so helpful, that I invested the time to mine it out of a trace. But clearly, running an MQ trace to get this type of data is not the best approach. It is heavy handed (all the I/O writes for the trace records) and it is difficult to mine it out of the trace. If IBM could do this RFE, I would be indebted  .
If you are an MQ administrator or someone else who deals with MQ performance on the distributed layer, please consider voting for:
RFE - http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=28409
To vote, locate the "RFE Actions" section on the right hand side of the screen and click the vote link.
I would greatly appreciate it!
Thanks,
Tim |
|
| 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
|
|
|
|
