| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Group as one physical message |
« View previous topic :: View next topic » |
| Author |
Message
|
| sumithar |
 Posted: Wed Jan 07, 2009 5:49 am Post subject: Group as one physical message |
 |
|
Apprentice
Joined: 13 Jun 2008
Posts: 47
|
In a couple of spots in the MQ primer (which does date back to 99) it mentions that messages can be (logically) grouped to be sent as one physical message
On pp5 it says
| Quote: |
"To reduce traffic over the network, you can also group several small messages together and build one larger physical message. This message is then sent to the destination and is there disassembled.
Message grouping also guarantees that the order the messages are sent in is preserved. " |
And again on pp9 when discussing functions of the queue manager:
| Quote: |
| It also can group messages and send them as one physical message to their destination where they are automatically disassembled |
But nowhere else in the literature do I see this mentioned. Every where else it talks about logical grouping as a technique to handle the situation when messages may land up in an order different to how they were put but the getting application needs them to be in order.
So is the Primer just out of date or what?[/quote] |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Jan 07, 2009 7:16 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I think that book is incorrect. Grouping is about a logical ordering of message.
As long as you don't send tiny messages over MQ (which would increase the ratio of management information to data payload) it won't make that much difference to the physical traffic. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 07, 2009 7:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I think the book was suggesting application level batching, rather than message grouping per se.
I.e. don't send one record when you can send 10, particularly if that one record is 500 bytes long.
But the Primer is generally out of date, I believe. |
|
| Back to top |
|
|
| sumithar |
| Posted: Thu Jan 08, 2009 8:38 am Post subject: |
|
|
Apprentice
Joined: 13 Jun 2008
Posts: 47
|
| thanks Jeff and Pat. Re-reading, it seems likely the author of the primer is talking about the application batching messages before sending to reduce n/w traffic. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 08, 2009 8:46 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
We have learned over time NOT to write application code to manage infrastructure (network capacity, disk space, cpu utilization) because infrastructure changes all to frequently.
The ROT (rule of thumb) way back then was to batch messages to ease the workload on MQ channels. What made sense in the era of slow networks (1999?) has become an (IROT) irrational rule of thumb.
Yes, one could argue that application batching still provides some relief, but newer tools (batchsize, batchinterval, compression), o/s-level facilities, and unimaginably faster networks, make application batching, and similar app-level code, a waste of programmer time and resources.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| sumithar |
| Posted: Thu Jan 08, 2009 10:42 am Post subject: |
|
|
Apprentice
Joined: 13 Jun 2008
Posts: 47
|
| It's like when were told to do SEND MAP DATAONLY at one time but nobody bothers much about that now given the improvement in network speeds. |
|
| 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
|
|
|
|
