| Author |
Message
|
| torr_chula |
 Posted: Thu Jan 25, 2007 5:02 am Post subject: TimeoutControl Performance Drop for Many Timeout Request Msg |
 |
|
Novice
Joined: 07 Nov 2006
Posts: 12
|
We've to schedule more than 100,000 messages for processing at a specified time by using the TimeoutControl node, and found that the performance of sending timeout request messsages to the TimeoutControl node decreases sharply while the amount of message in "SYSTEM.BROKER.TIMEOUT.QUEUE" increases.
Performance Test Result :
Time Used (Min.) : No. of Msg. in SYSTEM.BROKER.TIMEOUT.QUEUE
1 : 1081
2 : 1639
3 : 2098
4 : 2420
5 : 2740
6 : 3008
7 : 3276
8 : 3500
9 : 3744
10 : 3927
There're only about 17000 messages in the queue after 4 hours. I'm afraid that this rate will drop to an unacceptable rate when the messages in SYSTEM.BROKER.TIMEOUT.QUEUE is more than 100,000 messages.
Does anyone know how to deal with this problem ?
System Info:
WMB 6.0.0.2
AIX 5.3 ML2
WebSphere MQ V6.0.1.1 |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Jan 25, 2007 5:06 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You should certainly be able to scale horizontally, to distribute the load across multiple brokers and therefore multiple queues.
If you have many things that are supposed to happen at the same time, you'll want to do this anyway.
What's the size of your broker machine, anyway?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| torr_chula |
| Posted: Fri Jan 26, 2007 3:38 am Post subject: |
|
|
Novice
Joined: 07 Nov 2006
Posts: 12
|
| The speed for other flow types is OK (very much better) at the same loads. So, I think that this performance issue is specific to this feature only. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jan 26, 2007 4:33 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| torr_chula wrote: |
| The speed for other flow types is OK (very much better) at the same loads. So, I think that this performance issue is specific to this feature only. |
I'm not disagreeing with you.
I'm suggesting that you're probably trying something that is very heavy-weight for the design goals of the node, and that spreading the load out over multiple brokers is a good idea.
You can also look at tuning your queue manager - make sure you have sufficient log space for the volume you're pushing through during normal usage for example. Also I don't remember if one has much control over the messages on the timeout queue - but try and change the persistance to non-persistent, and maybe set the NPMCLASS on the queue to not delete non-persistent messages at startup.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| torr_chula |
| Posted: Fri Jan 26, 2007 4:54 am Post subject: |
|
|
Novice
Joined: 07 Nov 2006
Posts: 12
|
| jefflowrey wrote: |
I'm not disagreeing with you.
I'm suggesting that you're probably trying something that is very heavy-weight for the design goals of the node, and that spreading the load out over multiple brokers is a good idea.
You can also look at tuning your queue manager - make sure you have sufficient log space for the volume you're pushing through during normal usage for example. Also I don't remember if one has much control over the messages on the timeout queue - but try and change the persistance to non-persistent, and maybe set the NPMCLASS on the queue to not delete non-persistent messages at startup. |
Yes.. I also think that the developer of this feature may not designed it to support my scenario. The first thing I'll do is trying to tune the queue manager as your suggestion, but I don't have more brokers to spread the load. However, I have to change my design if I cannot successfully tune it. Thank you very much for your kind suggestion  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jan 26, 2007 5:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can put more than one broker on the same machine.
If that gives you concerns about the over all performance of the machine... then you probably need to buy bigger or more hardware.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
