| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Additional instances in broker |
« View previous topic :: View next topic » |
| Author |
Message
|
| manojsu |
 Posted: Sun Jul 12, 2009 11:16 am Post subject: Additional instances in broker |
 |
|
Centurion
Joined: 19 Jul 2006
Posts: 147
Location: Bangalore
|
Hi Guys,
A but confused bout the additional instances.
I have a 64 bit on which a flow is deployed with n instances set for the flow.
assuming there are x messages in the queue, and the processing power per message is equal. i would expect (x-in) (i=1,2,3..)messages processed.
But wat i can see from my current logging is that there are only 60 messages processed every minute.
I am not sure why are n simultaneos messages being consumed.
Please let me know as i am having much problems with people complaning of slow processing time.
Thanks
Regards
Manoj |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Sun Jul 12, 2009 11:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Suppose there are ten messages on the queue.
You deploy a flow with 0 additional instances that has one MQInput node.
The one MQInput node will use one thread to read one message at a time.
So after 10x, where x = time to process one message, the queue will be empty.
You then undeploy the flow, load 10 messages to the queue, and redeploy the flow with 4 additional instances.
The one MQInput node uses 5 threads to read 5 messages at a time. So the queue will be empty in, approximately, 2x.
Now, suppose that same flow has a critical section, or relies on a database or other resource that can only be accessed by one thread at a time.
Now your time to process goes back to something much closer to 10x. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Jul 12, 2009 10:17 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
To add on from mqjeff's comments
If you are using databases then Locking (especially with remote DB's) will become a problem. We got a 4x throughput improvement on one key flow by using PASSTHRU with optimised select statements to remove locks where were were only going to read data AND deploying the flow with multiple instances.
Only a prolonged and detailed set of benchmarking will tell you what number of additional instances will be right for your system.
Sometimes additional instances will NOT give you any extra throughput. It may be appropriate to try deploying the flow (with no additional instances) to another EG.
Again proper benchmarking will show which is best for your system.
_________________
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 |
|
|
| fjb_saper |
| Posted: Mon Jul 13, 2009 12:19 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you REALLY NEED throughput with a DB let me also suggest a different approach. Build an app to talk to a qmgr and talk to the DB. Note that for speed you will also need pooling. (if you have it available an app on a J2EE server does nicely here). You have then decoupled the broker from the DB. If your app is multithreaded and can scale easily you have also decoupled scaling from the broker.
Have fun 
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
