| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Message Flow Design Considerations |
« View previous topic :: View next topic » |
| Author |
Message
|
| SapanaK |
 Posted: Tue Mar 19, 2013 2:59 am Post subject: Message Flow Design Considerations |
 |
|
Newbie
Joined: 17 Sep 2012
Posts: 9
|
Hi All,
I have gone through the Infocenter help for topics covering ways to design/tune flows for optimised/scalable performance. And also through posts in this forum, and few dev works articles and ppts addressing performance related questions/issues.
I still have few queries, for which I couldn't find explanation, so I am raising them here, kindly advise.
The product version we are using is v 7.0.0.4.
1. How expensive is a compute node whose Compute mode property is set to 'LocalEnvironment' and OutputLocalEnvironment is empty? Basically to avoid copying of message tree. If the cost is to be compared to what is incurred with a filter node for example. Would the tree copy be still done for rolling input tree to its state at point of compute node, if there is an exception in subsequent nodes?
2. when we configure additonal Instances of a message flow, do all additional instances share the message flow code? To elaborate, what memory segments are shared at runtime - message flow code,heap and data? With each thread having its own stack? What I need to understand is how different additional instance configuration is to deploying multiple copies of same flow in sameEG(diff flow name) or different EG.
3. Is size of message flow to be considered for evaluating its memory consumption at run time? Would this increase with each additional instance configured? Recommended best practices suggest to use minimum number of nodes in a flow. Should this be considered from perspective of how many nodes an input message passes through at runtime or from static cost it adds? I have been told that every compute node results into 4KB addition to a message flow size, is that true?
4. With XMLNSC parser post WMB v6.1, is 'On demand' parsing still recommended? I have read on this forum that - for parsing scenarios XMLNSC parser is as fast when validating when it is not validating. So for traffic where 99% messages are expected to be well formed, 'On demand' and turning on validation should be the best configuration? |
|
| Back to top |
|
 |
| longng |
| Posted: Tue Mar 19, 2013 5:24 pm Post subject: |
|
|
Apprentice
Joined: 22 Feb 2013
Posts: 42
|
Somebody mentioned during the last few days about something to the effect reflecting the cliche of 'How long is a piece of string?'...
For all intents and purposes, it's not possible for anyone to provide you with any meaningful responses to your stated needs since apart from yourself (may be?). nobody would know how complex your message flows are, the specific input data that need to be processed, the environment etc. etc. I would want to add another adage: 'GIGO'!
In short, you would be the best person to answer your own questions posted here and the way to do that is to leverage your knowledge and the available tools. Let me give you some examples:
- To gauge the response time of Compute Nodes or any nodes to that matter, you certainly can use the Statistics capability of WMQ/WMB (Hint, in WMB Explorer, right-hand mouse click on a message flow or an execution group and you'll see). If you (or your colleagues, or your predecessors) apply the good practices in modularity etc. you may be able to drill down much more...
- To gauge resource consumption you can use some good old fashioned tools... I am sure you've heard of top, vmstat, mpstat, iostat etc. in Linux/Unixes, or even the good Windows task manager or advanced Windows' tool like process explorer from Sysinternals. How about Omegamon, Mainview, Strobe etc. on the good ol' irons?
Please do post back what you can find. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Mar 19, 2013 8:13 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| longng wrote: |
Somebody mentioned during the last few days about something to the effect reflecting the cliche of 'How long is a piece of string?'...
|
That was me! 
Once upon a time (back in the days of V2.0.1/V2.1) we used to care an awful lot about how expensive the different nodes were in CPU processing. Nowadays and unless you have a horribly complicated flow where the developer has insisted in wiring up every terminal on every node (they do exist) it really does not matter that much.
The advances in CPU technology in the last 10 years has made worrying about how expensive a Compute node is almost a thing of the past. That is not to ay that there may be cases where you need to be careful.
When I first started professional software development we would spend hours pouring over reams of assembler code trying to make it just that little bit more efficient/compact. This was mainly because the CPU's ran at KHz speeds and we had 8/16 K bytes of Ram to play with. (PDP-11/10)
This sort of optimisation is really not needed these days but I do think that some exponents of the Java (deconstruct everything into 1-3 line classes) could learn a thing or two from doing the sort of optimisation we had to do around 1975/76
_________________
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 |
|
|
| kimbert |
| Posted: Wed Mar 20, 2013 2:29 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I will be giving a presentation on WMB performance management and monitoring at the WebSphere UK User Group tomorrow. If you can get to IBM's South Bank office in London, then you'll be very welcome!
1. If you don't propagate OutputRoot then it cannot be changed by downstream nodes, so there is no need for rollback. So no costs associated with rollback either.
2. In most cases, adding additional instances requires no special code on the part of the developer. Exceptions include flows that use SHARED ROW variables, and flows that use Java singletons / static structures.
3. The number of nodes in a flow in unlikely to be the cause of high memory usage. Naive message flow design is far more likely to cause high memory usage.
4. On-demand parsing is the best default setting. Most message flows cannot tell whether it is on or off, because that's how it is designed. Flows that positively *require* on-demand parsing include flows that process a large input stream in small chunks ( to avoid high memory usage ).
When parsing, XMLNSC is very nearly as fast when validating as when not validating ( penalty is about 25% ). When writing, validation costs a little more. As always, your mileage will vary depending on the size and style of XML being processed by your flows. |
|
| Back to top |
|
|
| SapanaK |
| Posted: Wed Mar 20, 2013 4:33 am Post subject: |
|
|
Newbie
Joined: 17 Sep 2012
Posts: 9
|
Thanks everyone for your response!
@longng - thanks for the tools mentioned to gauge system memory/CPU consumption, I am looking at them, and would post findings.
@smdavies99 - I was of the same opinion - (This sort of optimisation is really not needed these days....), and your inputs reassure me of that. We tried to keep our design as modular as possible, seeking every chance for reuse - be at function level or procedure or subflow level - accepting bit of cost it might bring at runtime(at dev time, its the best bet, as they are thoroughly tested components which can be pluged in easily). Our systems showed some high memory utilisation symptoms, and while the cause is being analysed, the first comments from reviews indicated that we should reduce number of nodes(even if they werent incurring tree copy). And I suspected its not the root cause, and these clarification help be more confident about it.
@Kimbert - Thanks for session details, if you could please share the schedule of the presentation - very eager to attend it, would be the best opportunity to find answers to few queries and resolve few myths from the SME's directly! |
|
| 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
|
|
|
|
