| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Message Flow Design - Performance Consideration |
« View previous topic :: View next topic » |
| Author |
Message
|
| deepak_paul |
 Posted: Tue Jan 19, 2010 8:48 am Post subject: Message Flow Design - Performance Consideration |
 |
|
Centurion
Joined: 04 Oct 2008
Posts: 147
Location: US
|
All,
We have nearly 70 transactions in our project. Transactions are being implemented using Request/Reply messaging model with Input and Output Queues. While designing the transaction in WMB, we came across to acknowledge some performance considerations in our current design.
Current design:
MQ Input-->Check Transaction code(Compute)-->RouteMsgs(RouteToLabel)
Label1-->SubFlow1
Label2-->Subflow2
.....
Label10-->Subflow10
Subflow1-->Transaction category1(~7 Transactions)-->MQ Output
Subflow2-->Transaction category2(~7 Transactions)-->MQ Output
....
Subflow10-->Transaction category10(~7 Transactions)-->MQ Output
While thinking to use this design, we conceive a thought to create local Queue for each Transaction category so that we can aviod the whole dump of memory occupied by the subflows as it gets one flow when deployed.
If you have any good suggestion to recommend the new design or the old design itself, please share with us. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jan 19, 2010 9:11 am Post subject: Re: Message Flow Design - Performance Consideration |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| deepak_paul wrote: |
| While thinking to use this design, we conceive a thought to create local Queue for each Transaction category so that we can aviod the whole dump of memory occupied by the subflows as it gets one flow when deployed. |
Remember that even if you're using subflows in your design, it's all one big flow when it's deployed.
I would be surprised if memory being occupied (by subflows or anything else) was the bottleneck in this design. If it was me (and it's not of course) I'd stick with your concept of grouping similar transactions into subflows (if the grouping is simple), but certainly use one queue for each transaction. Queues are cheap and it's going to be easier to track & monitor 70 queues than the contents of 10 queues. It would also simplify the logic of whatever's reading the queues as it doesn't have to sort or filter by transaction type.
My 2 cents, other design solutions are equally valid and may be better, etc, etc.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| deepak_paul |
| Posted: Tue Jan 19, 2010 10:24 am Post subject: Re: Message Flow Design - Performance Consideration |
|
|
Centurion
Joined: 04 Oct 2008
Posts: 147
Location: US
|
Thanks Vitor.
| Vitor wrote: |
| ...I would be surprised if memory being occupied (by subflows or anything else) was the bottleneck in this design... |
Can you please explain how memory utilisation would NOT be taken into consideration, though it is all one big flow when it's deployed, as said.
http://www.mqseries.net/phpBB2/viewtopic.php?t=45761 |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 19, 2010 10:53 am Post subject: Re: Message Flow Design - Performance Consideration |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
The thread you refer to spoke of "1000+" interfaces; you have 70. If you had 700 I'd have given a different answer.
IMHO the solution I outlined is the best bet for your situation. If you feel the method given in the other thread works better for you I wouldn't disagree. For most designs there are a number of solutions each with positive and negative points and you select one using your best judgement. For other designs there are some solutions which are clearly impractical or unworkable & can be dismissed from consideration almost immediately.
You are in the former position, and have a number of possible solutions from which you must pick one. If you're looking for authoratative guidance on which solution is the most memory efficient, I recommend a prototype and some monitoring.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| deepak_paul |
| Posted: Tue Jan 19, 2010 12:03 pm Post subject: |
|
|
Centurion
Joined: 04 Oct 2008
Posts: 147
Location: US
|
| Thanks for your help, Vitor. |
|
| 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
|
|
|
|
