| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Adverse effects of Event Monitoring on Flow Perfomance |
« View previous topic :: View next topic » |
| Author |
Message
|
| ashwgupt |
 Posted: Thu Nov 06, 2014 9:58 am Post subject: Adverse effects of Event Monitoring on Flow Perfomance |
 |
|
Novice
Joined: 31 Oct 2011
Posts: 12
|
I am posting this question here as failed to find any clear documentation or information available elsewhere. Please redirect me to the url/doc if any present already on this topic.
We are using Flow Monitoring for Events generation and we store them in record and replay DB.
Though I know and understand that, Event emission and processing happens in a separate thread/UOW than that of main flow but am trying to certain if event emission can have any adverse effect on the flow performance.
If any, what shall be the factors (like event data size/frequency/recording latency etc.) that one considered during implementation of the same to keep the effect to minimum.
Can one also tell, if the threads used by event monitoring are those taken from the thread pool of the message flow. Because if that's the case, in a heavily used flow, there can be a thread starvation situation faced at times.
Any thoughts are welcome |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Nov 06, 2014 10:07 am Post subject: Re: Adverse effects of Event Monitoring on Flow Perfomance |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ashwgupt wrote: |
| Though I know and understand that, Event emission and processing happens in a separate thread/UOW than that of main flow but am trying to certain if event emission can have any adverse effect on the flow performance. |
Not flow performance, as it's a different thread. I believe the quoted figure is a 2% hit on overall performance.
| ashwgupt wrote: |
| If any, what shall be the factors (like event data size/frequency/recording latency etc.) that one considered during implementation of the same to keep the effect to minimum. |
It's everything you'd expect. A monitoring event is an block of data WMB has to assemble and publish so there's a fixed overhead for the data points, plus additional overhead for any data you've specified by XPath. So if you want the whole payload in the event plus the payload as a base64 string it's going to cost more than an event with no data and get you closer to that maximum hit I mention above.
The actual effect of differing loads in your specific set up is something you'll have to determine yourself through testing.
| ashwgupt wrote: |
| Can one also tell, if the threads used by event monitoring are those taken from the thread pool of the message flow. |
No. The flow doesn't have a "thread pool". The number of threads is controlled by the execution group, which will (if needed) spin up additional threads up to the limit given by the additionalInstances parameter. If the EG is so short of resources it can't spin up threads to perform event handling, you have much bigger resource problems than the event handling.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ashwgupt |
| Posted: Thu Nov 06, 2014 10:12 am Post subject: |
|
|
Novice
Joined: 31 Oct 2011
Posts: 12
|
Thanks a lot Vitor for such a speedy reply...It will really help.
Can you pls also point me the documentation, if any, that may have the mention of this overhead? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Nov 06, 2014 10:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ashwgupt wrote: |
| Can you pls also point me the documentation, if any, that may have the mention of this overhead? |
If it's not in the record & replay documentation then it's a red book someplace.
Probably easier and more reliable to run some speed trials on your environment especially if this kind of marginal impact is a cause for concern in your set up. Test results always trump either online documentation or the views of random strangers on the Internet.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
