| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Message Broker Monitoring Events Performance |
« View previous topic :: View next topic » |
| Author |
Message
|
| qrm1139 |
 Posted: Tue Jun 19, 2012 1:33 pm Post subject: Message Broker Monitoring Events Performance |
 |
|
Newbie
Joined: 19 Jun 2012
Posts: 3
|
Hello folks,
I recently found out Event Monitoring capability within MessageBroker and was very excited to use it because it would provide auditing capabilities. However, I was asked to do performance evaluation on it with events turned on and off. The flow which I used for this experiment was very simple comprising of MqInput --> Compute -->MQOutput nodes. Also, I did this on my local windows xp machine. Also I simulated the load with RFHUTIL tool.
Below is the statistics with Load of 241 messages:
Events Turned ON:
Snapshot time -2012-06-18 11:23:48.085 -2012-06-18 11:24:06.861
Broker MB7BROKER
Execution Group default
MessageFlowName PerformanceFlow
TotalElapsedTime 2532000
MaximumElapsedTime 109000
MinimumElapsedTime 15000
TotalCPUTime 281250
MaximumCPUTime 15625
MinimumCPUTime 15625
Events Turned OFF:
Snapshot time -2012-06-18 11:23:48.085 -2012-06-18 11:24:06.861
Broker MB7BROKER
Execution Group default
MessageFlowName PerformanceFlow
TotalElapsedTime 31000
MaximumElapsedTime 16000
MinimumElapsedTime 15000
TotalCPUTime 15625
MaximumCPUTime 15625
MinimumCPUTime 15625
Looking at the above statistics tells me Monitoring Events are not that efficient. Please let me know what you guys think. |
|
| Back to top |
|
 |
| kimbert |
| Posted: Tue Jun 19, 2012 2:17 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
1) Obviously, emitting a monitoring event is going to have an impact on performance - for each individual event you are constructing/emitting another message from your message flow. Depending on the settings that you have chosen for 'units of work', the event(s) might also incur extra transactional costs.
2) You did not say exactly which events/bit streams you were emitting. Did you simply switch on monitoring and rely on the settings in the default monitoring profile?
3) There are lots of satisfied users of WMB monitoring events and auditing - as always, it comes down to requirements. I'm fairly sure there will be a way to design your flow that achieves your goals. |
|
| Back to top |
|
|
| qrm1139 |
| Posted: Tue Jun 19, 2012 2:57 pm Post subject: |
|
|
Newbie
Joined: 19 Jun 2012
Posts: 3
|
| kimbert wrote: |
1) Obviously, emitting a monitoring event is going to have an impact on performance - for each individual event you are constructing/emitting another message from your message flow. Depending on the settings that you have chosen for 'units of work', the event(s) might also incur extra transactional costs.
2) You did not say exactly which events/bit streams you were emitting. Did you simply switch on monitoring and rely on the settings in the default monitoring profile?
3) There are lots of satisfied users of WMB monitoring events and auditing - as always, it comes down to requirements. I'm fairly sure there will be a way to design your flow that achieves your goals. |
Kimbert, thanks for your prompt reply.
1) I agree there would be some performance impact with event monitoring turned on, but I didn't expect it to be that much, as somewhere in this forum I read event monitoring is light weight.
2) I did not capture bitstream's as I wanted it to keep it very simple. I emitted transactional events for the MQInput node and 2 terminal events, one for output of the InputNode and other for the input of the output node. I didn't generate any events in the intermediate node. Yes, you are right I didn't do any changes to the monitoring profile, I used the default one as is. Can you please point me to a doc which can help me tune the monitoring profile?
3) Yes I agree, I have read several threads on this forum where people were happy using Monitoring profile as it provides lot of valuable info. without coding. But I am afraid my architecture team won't approve the use of Event Monitoring because the statistics on it don't look that good.
If this inbuilt event monitoring functionality is rejected by my architecture team, I will have to create a similar one of my own, using flow level properties of MB. I am not sure though if I will be able to capture all the info. which event monitors provide.
Has anyone tried to build their own auditing system and not use the one in MB? I want it similar to the inbuilt functionality and should be able to capture transactional events and terminal events. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 19, 2012 4:32 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| qrm1139 wrote: |
| Has anyone tried to build their own auditing system and not use the one in MB? I want it similar to the inbuilt functionality and should be able to capture transactional events and terminal events. |
Yes I have. It sucks. It's a lot of code to maintain to try and reinvent that wheel.
Disclosure: I'm one of the satisfied users @kimbert mentions. I've not seen the kind of performance hit you describe.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| goffinf |
| Posted: Wed Jun 20, 2012 12:18 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| qrm1139 wrote: |
| Has anyone tried to build their own auditing system and not use the one in MB? I want it similar to the inbuilt functionality and should be able to capture transactional events and terminal events. |
We were doing something like this using a custom node for a few years with v5, pushing messages out to Log4j. When we came across monitoring events we switched and have been using them ever since. For the purpose of harvesting flow metrics we typically emit only an event at the start and end of the flow. We have used them in flows which have thruput of 50msg/sec without significantly impacting performance, at least in terms of the SLA we need to achieve.
Actually a more difficult problem we had, at least until recently, was in analysing the event output into meaningful information that we could act on. That is, aggregating the results into useful statistics we could use for understanding the profile of our MB software across time. Recently we've taken to using Splunk for this purpose and it works very nicely. We also use monitoring events underneath our general logging and error frameworks, and again, the ability to take the raw event data, correlate multiple events across time to form a good diagnostic picture of what occurred is really helpful to our support folk (MBv8 has more of this sort of thing built in but we're going to be on 6.1 for a little while longer).
So, whilst it nearly always possible to write a custom solution that is more optimised, you have to ask yourself whether (a) you have the expertese to develop it in the first place, and (b) you are prepared to maintain it over time. A major reason for using products like Broker, as opposed to a general purpose programming approach, is that you get a lot of rich functionality OOTB, that is maintained and documented by the vendor, i.e. the people that know the most about the technology. Such features will be used by lots of customers, so you also benefit from other peoples experience via forums such as this one.
I'm not saying that in your case performance isn't an over-riding characteristic, and it's possible that the in-built monitoring events won't be able to meet your particular demands, although I'd be a little surprised. You probably need to do a little more testing than the small run that you have suggested, trying as far as you can to simulate your 'real world' environment for concurrency and other resource use. If performance testing has shown me anything, it's that most of the time you are trying to find where your resource constraints are, and then moving them to the place which is most advantageous (i.e. where you have more and/or cheaper availability). Simple tests often yield results that don't reflect reality (and it's easy to slip into counting milli-seconds, when the 'elephant in the room' is that you have 'n' seconds of [Inter]network latency).
So I personally would think hard about whether to take the bold step of building something yourself before I exhausted all the potential in the product itself.
Good luck
Fraser. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jun 20, 2012 12:22 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| I didn't do any changes to the monitoring profile |
Well, you did actually. If you set monitoring properties via the node properties then you override the default monitoring profile ( but note that if you deploy your own monitoring profile then it will override the node settings ).
re: the performance, your initial test was a reasonable sniff test but there are more rigorous ways to performance test a message flow. |
|
| Back to top |
|
|
| qrm1139 |
| Posted: Wed Jun 20, 2012 7:53 am Post subject: |
|
|
Newbie
Joined: 19 Jun 2012
Posts: 3
|
| kimbert wrote: |
| Quote: |
| I didn't do any changes to the monitoring profile |
Well, you did actually. If you set monitoring properties via the node properties then you override the default monitoring profile ( but note that if you deploy your own monitoring profile then it will override the node settings ).
re: the performance, your initial test was a reasonable sniff test but there are more rigorous ways to performance test a message flow. |
Thankyou Kimbert, Vitor and goffinf(Fraser) for your valuable inputs. I have been reading your other posts as well and you guys are excellent.Keep up the good work. |
|
| 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
|
|
|
|
