| Author |
Message
|
| kirank |
 Posted: Mon Nov 28, 2011 11:53 am Post subject: WMB resource and Statistics |
 |
|
Centurion
Joined: 10 Oct 2002
Posts: 136
Location: California
|
We are planning to enable WMB resource and statistics for message flows and collect monitoring messages using Pub/Sub option so that we can do some reporting based on those messages. I read in one of the SHARE conference PDF's that there is an 8% overhead for collecting these statistics. I can not find any other documentation related to that in Info center.
Does anybody know what is the performance overhead if we were to keep resource and statistics enabled in Production?
regards
Kiran |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Nov 28, 2011 12:12 pm Post subject: Re: WMB resource and Statistics |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kirank wrote: |
| Does anybody know what is the performance overhead if we were to keep resource and statistics enabled in Production? |
I'd be interested in a link to that PDF.
I've never seen anything in print on monitoring overhead (which could easily mean I've overlooked some printed material!) and would welcome such a statement.
Anecdotially I can tell you that a WMBv6.1 broker estate of mine didn't show any detectable overhead collecting stats in this manner, but it wasn't really a high volume, stressed environment & we had a separate box which collected & processed all the stats to keep that processing load off the "live" servers.
Not sure if that helps or not but there it is for what it's worth.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kirank |
| Posted: Mon Nov 28, 2011 12:43 pm Post subject: |
|
|
Centurion
Joined: 10 Oct 2002
Posts: 136
Location: California
|
Actually the 8% overhead was mentioned in the the article below.
http://www.ibm.com/developerworks/websphere/library/techarticles/0710_piatek/0710_piatek.html
The Message Broker Performance SHARE in Boston Pdf mentions 3% overhead.
It goods know you did not experience detectable amounts of performance degradation. Hopefully in V7 it should be even better. We are planning similar non-intrusive monitoring where the monitoring application itself will run on separate server than WMB.
Regards
Kiran |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 28, 2011 12:48 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Thanks for posting.
We didn't use any of the supplied tools for display or analysis; we processed the XML (via a series of flows) into CSV files that disappeared off into the site's SLA monitoring, cross-charging and accounting systems. None of it real time, various reports were produced at various intervals and were occassionally waved at meetings.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Nov 28, 2011 10:31 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Running Flowstats with node level collection for any length of time in a production system is IMHO 'just plain crazy'.
I'd probably run flow monitoring 24/7 if I was interested in how many times a service was invoked (for chargeback etc).
Naturally, this data will give you usage patterns as well.
eg, why are so many customers updating their data between 8pm and midnight on a Sunday? Nowt on TV then? (This is allowed btw but the usage patterns are fascinating)
But Flowstats are ONLY ever enabled for a specitifc flow and for a limited time.
Every site will have a different requirement and the loading that applies to your site can only be determined by proper testing with your workload mix.
My 'just plain crazy' statement may well be overruled by some odd requirements at certain sites.
_________________
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 |
|
|
| McueMart |
| Posted: Tue Nov 29, 2011 4:57 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
The performance impact will probably differ quite significantly depending on the the level of statistics you have (Node/Terminal/Thread etc) and the number of nodes/threads in your flow.
Easiest way would just be to benchmark it for your specific purpose! |
|
| Back to top |
|
|
| kirank |
| Posted: Wed Nov 30, 2011 11:42 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2002
Posts: 136
Location: California
|
Yes I agree that running flow stats for extended period is not a good idea. I am thinking of enabling statistics for a short period of time to collect data and then disable it so that we can do some reporting/trending based on data collected.
Regards
Kiran |
|
| Back to top |
|
|
|
|
