| Author |
Message
|
| Raji123 |
 Posted: Tue Jun 14, 2011 8:46 am Post subject: WMB- performance test |
 |
|
Newbie
Joined: 14 Jun 2011
Posts: 1
|
Hi,
It would be helpful if someone let me know how to calculate the response time in my message flow with node level for performance testing |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jun 14, 2011 8:50 am Post subject: Re: WMB- performance test |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Raji123 wrote: |
| It would be helpful if someone let me know how to calculate the response time in my message flow with node level for performance testing |
Enable & configure the flow & node monitor events?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jun 14, 2011 10:07 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
You could do that, but you would not get any useful info regarding performance tests that way, since the act of collecting such will skew your results.
An alternate method is to create a POJO, timestamp send time, send transaction, timestamp reply time, subtract the two. The result of this is end-to-end latency.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 14, 2011 10:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| You could do that, but you would not get any useful info regarding performance tests that way, since the act of collecting such will skew your results. |
Again I call upon you to justify that broad brush statement, specifically the part that the information collected would not be "useful". Please provide justification for your assertion that the publication of event messages (not their collection and analysis which would be performed offline) would soak so much & such a variable amount of resources as to render the process useless. Especially since even the "skewed" results would demostrate an abnormal amount of time spent in a given part.
| lancelotlinc wrote: |
| An alternate method is to create a POJO, timestamp send time, send transaction, timestamp reply time, subtract the two. The result of this is end-to-end latency. |
And how do you extend this method to measure time at node level, as the OP indicated?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 14, 2011 10:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
You could do that, but you would not get any useful info regarding performance tests that way, since the act of collecting such will skew your results.
An alternate method is to create a POJO, timestamp send time, send transaction, timestamp reply time, subtract the two. The result of this is end-to-end latency. |
Aside from all of the rest of the perfectly reasonable objections to this idea, Raji123 specifically asked about node-level performance. And that's not remotely the same thing as end-to-end latency. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 14, 2011 11:22 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Support pac IH03 has various performance testing utilities. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 14, 2011 11:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| Support pac IH03 has various performance testing utilities. |
Which, again, mostly test end-to-end latency, rather than node-level statistics.
But is at least a valid option to "create a POJO".
If you need node level statistics, you either need Broker Accounting & Statistics or Monitor Events.
Or something that can carefully parse and understand service tracing (although enabling this also causes a performance hit... )
but again, presumably one is looking for the comparative values of each node - this node takes 30% longer than other nodes - rather than an absolute measurement. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 14, 2011 11:33 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Why, in eleven years of using WMB (and pre-cursors), I've never needed to do this?
The product is vastly faster than it used to be. Just write decent code, use debug to make sure the code path is sensible and run the thing. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 14, 2011 11:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| Why, in eleven years of using WMB (and pre-cursors), I've never needed to do this? |
Presumably to show that the problem is not actually in WMB or WMQ. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jun 14, 2011 11:44 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
@Vitor
I was too subtle in my challenge to the OP. zpat asserted the same thought: Why do we care about performance node-to-node if the overall performance of the flow latency is satisfactory?
If one was developing a custom node, I see the value in node-level perf stats.
If one is developing an end-user business flow, as long as the latency is reasonable, there is no reason to know the minute details of a node.
The OP asked to calculate the response time. Response time implies an end-to-end measurement. You do not get response from most nodes. It takes more than one node in a flow to come up with a Request-Reply response. Therefore, the phrasing of the OP's original post implies measurement of more than one node, or end-to-end.
There is no "response" from any single node. For example, you need a SoapInput and a SoapReply to have a response.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 14, 2011 11:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| There is no "response" from any single node. For example, you need a SoapInput and a SoapReply to have a response. |
I would assert that a SOAPRequest node generates a response.
I would assert that an MQGet node generates a response (even if it's not a reply).
I would assert that a FileRead node generates a response.
I would assert that knowing how long each of those specific nodes took, rather than how long it took the whole flow to run, has specific and meaningful value. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jun 14, 2011 11:52 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Its possible that there is value there. My point (and I think zpat's point), no need to dig into the nitty gritty for most end-users if it works well to begin with.
End-to-end performance testing is satisfactory for most business users.
The same is not true if you developing nodes for WMB pallete. Then I see a value for node-level stats.
The point is unimportant, as it will not change the price of gas. So I yield to your thoughts and Vitor's thoughts.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 14, 2011 12:08 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| End-to-end performance testing is satisfactory for most business users. |
And when it's not satisfactory what do you do, if not get down into the "nitty gritty" of the flow? How do you know that this is not where the OP is, having determined this flow performs badly, and needs to determine exactly where the problem is?
| lancelotlinc wrote: |
| The point is unimportant |
The point is very important. You posted, where an inexperienced person could see it, that monitor events produce useless and/or misleading results without any qualification of that statement. You then posted that you needed to know Java to extract this information from WMB.
Both of these opinions are valid, but are opinions. Remember Google will not throw this post up in 6 months with context when the next untrained victim with a performance problem (because they're not running Power7) searches for "WMB performance monitoring".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Jun 14, 2011 10:30 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
The point is very important. You posted, where an inexperienced person could see it, that monitor events produce useless and/or misleading results without any qualification of that statement. You then posted that you needed to know Java to extract this information from WMB.
|
Hmm. FlowMonitoring & potentially misleading results.
I posted a note on this very topic.
http://www.mqseries.net/phpBB2/viewtopic.php?t=57743 onle a week or so ago.
Because of this lag you should use terminal events. These don't seem to show this problem.
But, as with any measurements you take, you have to remember that the simple fact of configuring the system so that you can take those measurements WILL AFFECT THE OVERALL PERFORMANCE of the system.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 15, 2011 4:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| But, as with any measurements you take, you have to remember that the simple fact of configuring the system so that you can take those measurements WILL AFFECT THE OVERALL PERFORMANCE of the system. |
I'm not disputing that. I'm disputing that configuring the flow to generate those events will have a significant affect on the overall performance of the flow, and I'm disputing the assertion that this method does not generate useful info.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
