| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Question concerning MQ Best practices for large messages |
« View previous topic :: View next topic » |
| Author |
Message
|
| JohnRodey |
 Posted: Wed Jun 01, 2005 7:55 am Post subject: Question concerning MQ Best practices for large messages |
 |
|
Centurion
Joined: 13 Apr 2005
Posts: 103
|
Our system must be able to handle large messages of about 70 Megs or possibly more. I know MQ can be set to handle messages of up to 100Mb.
If you know the maximum size that a message can be is it better to make the queue able to store the entire message or to have your application break it up into smaller chunks and send it as a group of messages?
Since most messages will not be 70 Mb, some (if not most) may be as small as 1/4 Mb, does it make your system any less performant by setting the max message size to be 100 Mb?
Thanks for any help! |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Jun 01, 2005 8:02 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I always configure new queue managers to support 100MB messages.
Then I don't get phone calls in the middle of the night from operations saying that some programmer decided to send a 95MB message and it couldn't go through, because the qmgr was only set to support 90MB messages.
In cases where there are partner qmgrs that do not support larger messages, it's best to limit the queue definintions on your side so that the programmer gets a bad return code on the put, rather than having to deal with it on the DLQ.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jun 01, 2005 6:00 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
1 70 MEG message or 700 1 MEG messages. Well, the end result is the same, but consider moving this data between 2 QMs. The 70 Megger will take a bit of time to be moved across the channel, during which time no other messages can be shipped. Whereas the 70 1 Meggers would allow the possability of other messages to be intermingled and not delayed.
Also, consider what happens for the channels batch processing. If the channel batch size is set to the default of 50, and your channel sends of few of those 70 Meggers in a batch, it will take along time to backout if it needs to. If the app puts the messages fast enough to the XMITQ so that the Batch Interval doesn't get a chance to tell the channel to end the batch, now you got a batch of 50 70 Meg messages = 3.5 GIG = getting close to exceeding your log space if you happened to make them as big as possible.
If there are other applications using these QMs to ship messages, and they are significantly smaller, and time sensitive, then this is one of the few times that multiple channels between 2 QMs makes sense. Make a second "FAT" channel, that will be used to ship these huge messages. Meanwhile the regular channel can quickly move the smaller messages.
All things being equal, if the app can easily break the messages up, you are probably better off.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Jun 02, 2005 12:08 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
When a channel is moving a very large msg it needs to allocate a lot of heap memory, to read the msg from the queue, and possibly to convert it as well. If the heap memory is not available to the process then the channel will fail.
I suggest that if you need large msgs you enable msg segmentation so that the msgs are stored and transmitted as msgs of the max msg size, but can be put and got as complete msgs with the appropriate MQPMO and MQGMO options. |
|
| 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
|
|
|
|
