| Author |
Message
|
| gunter |
 Posted: Wed Apr 08, 2009 12:31 am Post subject: MAXMSGL impact |
 |
|
Partisan
Joined: 21 Jan 2004
Posts: 307
Location: Germany, Frankfurt
|
Hi,
the default for MAXMSGL is 4194304. What is the benefit from decreasing ist to the size really needed?
Is there any impact on performance and/or used ressources?
Thanks
Gunter
_________________
Gunter Jeschawitz
IBM Certified System Administrator - Websphere MQ, 5.3 |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Wed Apr 08, 2009 4:06 am Post subject: Re: MAXMSGL impact |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| gunter wrote: |
Hi,
the default for MAXMSGL is 4194304. What is the benefit from decreasing ist to the size really needed?
Is there any impact on performance and/or used ressources?
Thanks
Gunter |
The main benefit of decreasing MAXMSGL is to prevent apps from accidently putting messages to the queue that are longer than expected, and hence use more space in MQ, and perhaps upset the consuming app. Its like giving someone small envelopes to post all their letters rather than huge packing crates.
There is no impact on performance or used resources just by setting MAXMSGL.
_________________
Glenn |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Wed Apr 08, 2009 5:24 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
According to IBM's best practices:
The MaxMsgLength parameter stores the value for the maximum size of a message allowed on the queue. The 4 MB default can be changed to better align with your application processing needs, which will have the benefit of using system resources in the most efficient manner. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Apr 08, 2009 7:59 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Personally, I've always found the MaxMsgLength attribute to be an artificial limit that causes more problem then it solves.
i.e.
A lot of companies use it to limit the message size that an application can receive (i.e. set it to 32768). Then 1 or 2 years later, a request will come in to accept a new message size. Everything will work in 'Test' but as soon as it is deployed to 'Prod' it breaks. Now, everybody spends several hours trying to figure out what the problem is, only to remember that MaxMsgLength was set several years ago and of course everybody blames MQ for the problem.
MaxMaxLength is like a "speed-limiter" or "speed governor" on a car. It is not needed as serves no value. Personally, I say set MaxMsgLength to 100MB on all queues and then forgot about it.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 08, 2009 8:16 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I disagree with you on this one Roger. If you set it to 100MB, and the apps are all sending 1K messages, things are fine. Then a couple of years down the road an app starts sending 100MB messages. Everyone wastes hours, days and weeks chasing down why "MQ is slow", becasue the MQ Admins don't realize there are chubby 100MB messages slooooowly moving from QM to QM, slowing down the little 1K messages.
I set the limit to 1MB, and if an app comes in that is going to send big messages, it won't be by surprise, giving me a chance to make an educated decision - just bump the size, or give them their own channels or give them their own QMs or give them their own MQ servers.
App queues and SVRCONN channels are all set to 1 MB for me, unless they need to be bigger. All shared system parms, like max message length for the QM, the DLQ, the XMITQs the SNDR/RCVR channels are set to 100MB.
Glenn,
You said "Its like giving someone small envelopes to post all their letters rather than huge packing crates. "
Not quite a perfect analogy. If you use a crate to send me a birthday card, there will be a lot of unneccessary performance impact and cost. If you set a channel to 100MB to send a 10 byte message, there is no overhead at all versus if the channel was set to 1K max message length.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Apr 08, 2009 8:30 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi Peter,
The question did not mention QMgr to QMgr traffic. If we include that topic then my answer would also include multiple channels between QMgrs. I would have a "batch" and "light" channels between 2 QMgrs. The "batch" channel would have a 100MB message size limit and the "light" channel would 1MB (or smaller) message size limit.
I have have even done QMgr setups where I have 3 channels between 2 QMgrs: "super light", "light" & "batch". Where "super light" has a 32KB message size limit, the "light" channel had a 2MB message size limit and the "batch" channel had a 100MB message size limit.
Hence, all local queues would have the 100MB message size limit but QMgr to QMgr traffic must take the appropriate "highway".
Anyway, there are many ways to fry a catch-fish. 
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 08, 2009 8:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The question specifically asked if there was any benefit from decreasing MAXMSGLN.
The answer is "no".
As for a 100Mb message "slowing down MQ", if you build and design everything *up front* and assume you'll pass 100 Mb messages *eventually*, then you shouldn't get too surprised later down the road. And they're also a *lot* less likely to call you in the middle of the night over an intermittent performance problem than they are over an app that is persistently failing to send a message bigger than MAXMSGLN. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 08, 2009 9:05 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
C'mon Jeff, you live in the real world. 
You can tell them eventually their will be big messages and eventually there will occasionally slowdowns, but after 2 years of no big messages, they get used to the performance and will complain when it slows down, especially if no one realizes why. Especially when all the original people have left that were involved in the original design and decisions.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Apr 08, 2009 9:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I'd guess that maxmsglength attribute of queues and channels is used by mq buffer management routines to acquire buffers for messages; so there is some small overhead in real storage.
Admins use these same attributes to constrain errant applications from misusing valuable resources (real storage, I/O).
_________________
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 |
|
|
| mqjeff |
| Posted: Wed Apr 08, 2009 9:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
C'mon Jeff, you live in the real world.
You can tell them eventually their will be big messages and eventually there will occasionally slowdowns, but after 2 years of no big messages, they get used to the performance and will complain when it slows down, especially if no one realizes why. Especially when all the original people have left that were involved in the original design and decisions. |
I didn't say they wouldn't complain.
I said they were much less likely to call you in the middle of the night over a performance issue than over an app getting an MQCC_FAILED. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Wed Apr 08, 2009 12:32 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| bruce2359 wrote: |
I'd guess that maxmsglength attribute of queues and channels is used by mq buffer management routines to acquire buffers for messages; so there is some small overhead in real storage.
Admins use these same attributes to constrain errant applications from misusing valuable resources (real storage, I/O). |
From the IBM's best practices, it appears to be a performance overhead when we use the maxmsgl to be a bigger value.
In an organization where the higher throughput is highly required, as an admin we have to tune MQ where ever possible like by setting the maxmsgl to a lower value I believe.
Thanks. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Apr 08, 2009 1:04 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| the maxmsgl to be a bigger value |
Not to pick nits or be pedantic...
Maxmsgl should be no larger than necessary is the best-practice. Necessary to me means the sum of current msg length + estimated msglength growth over a known time-period + some fudge-factor.
Fudge-factor: n. A variable factor or component used in calculations or experiments that allows for a margin of error or produces a desired result.
Setting maxmsgl to 100Meg when 4Meg is necessary (all messages less than or equal to 4Meg) is an overkill. Although, this will satisfy Jeff's fear of the unknown.
If current estimate from developers is for 3 or 3.8Meg, I might set maxmsgl to a nice 4Meg round number.
This is a trade-off between overallocating resources needlessly (or unknowingly) and having to revisit maxmsgl attributes too frequently in response to growth-related app failures.
Again, max values server two purposes: reduce demand for resources, and constrain errant applications.
_________________
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 |
|
|
| Sam Uppu |
| Posted: Wed Apr 08, 2009 1:22 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| Quote: |
Quote:
the maxmsgl to be a bigger value
Not to pick nits or be pedantic... |
My apolozies. Its typo. It should be "should not be big" |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Apr 08, 2009 1:30 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| My apolozies. Its typo. It should be "should not be big.. |
Apologies not necessary. I knew what you meant.
_________________
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 |
|
|
| gbaddeley |
| Posted: Thu Apr 09, 2009 2:16 am Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bruce2359 wrote: |
| Quote: |
| the maxmsgl to be a bigger value |
Not to pick nits or be pedantic...
Maxmsgl should be no larger than necessary is the best-practice. Necessary to me means the sum of current msg length + estimated msglength growth over a known time-period + some fudge-factor.
Fudge-factor: n. A variable factor or component used in calculations or experiments that allows for a margin of error or produces a desired result.
Setting maxmsgl to 100Meg when 4Meg is necessary (all messages less than or equal to 4Meg) is an overkill. Although, this will satisfy Jeff's fear of the unknown.
If current estimate from developers is for 3 or 3.8Meg, I might set maxmsgl to a nice 4Meg round number.
This is a trade-off between overallocating resources needlessly (or unknowingly) and having to revisit maxmsgl attributes too frequently in response to growth-related app failures.
Again, max values server two purposes: reduce demand for resources, and constrain errant applications. |
I think that was the best post so far on this topic. I usually ask the app designer for the maximum message size the queue is likely to use, and then double it to set MAXMSGL. The same rule applies to setting MAXDEPTH. This minimises the likelihood of DoS scenarios where one app can fill /var/mqm by misuse (accidental or otherwise) of MQ.
I doubt that MQ preallocates buffers of MAXMSGL size. It would only allocate buffers to cope with whatever size of message it was processing at the time.
_________________
Glenn |
|
| Back to top |
|
|
|
|
