| Author |
Message
|
| Goodfellas |
 Posted: Tue Nov 23, 2010 11:01 am Post subject: SETTING |
 |
|
Acolyte
Joined: 26 Feb 2009
Posts: 70
|
Thanks
Last edited by Goodfellas on Tue May 28, 2013 12:19 pm; edited 1 time in total |
|
| Back to top |
|
 |
| zpat |
| Posted: Tue Nov 23, 2010 11:49 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You've forgotten the DLQ. You also may need to update CCDTs.
More memory will be used for application and queue manager buffers. I assume these are persistent messages?
Log space used may increase depending if they are syncpointed and how many are processed concurrently.
Any message browsing or manipulation tool may struggle to cope with these size messages, making support harder (and a MQ client setup using such tools will also need their svrconn channel sizes changed, if the tool can cope).
The easiest thing to do is try it out. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Nov 23, 2010 12:00 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The easiest thing to do is try it out. |
But, you can calculate with some degree of precision.
Actual message size (length), not the MAXMSGL attribute value, impacts disk space, i/o transfer time, and processor utilization.
_________________
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 |
|
|
| Goodfellas |
| Posted: Tue Nov 23, 2010 12:43 pm Post subject: |
|
|
Acolyte
Joined: 26 Feb 2009
Posts: 70
|
So
Last edited by Goodfellas on Tue May 28, 2013 12:19 pm; edited 1 time in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 23, 2010 1:14 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Goodfellas wrote: |
So If Take Care of the Disk Space & MQ Log Files....Setting 100 MB will not be an issue?
Do we see any MQ performance issues or impacts when we set
the MAXMSGL to 100 MB |
Of course you will see a performance impact.
Start with memory allocation (you'll need way more) go to message time transfer (don't forget the handshakes and CRC checks ) etc ... channel response times etc...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Nov 23, 2010 1:16 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| So If Take Care of the Disk Space & MQ Log Files....Setting 100 MB will not be an issue? |
You will need to consider both disk and network i/o transfer in the great Service Level Agreement (SLA) equation, too. 100MB takes a bit longer to transfer to and from than 4MB.
The WMQ client is not the stellar network performer that WMQ point-to-point channels are. Client apps impose additional flows for CC/RC across the network. Consider network bandwidth in the equation, too.
Presuming that the hardware platform is sufficiently provisioned, and that you are not suddenly increasing all msgs to 100MB, you should be able to manage.
_________________
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: Tue Nov 23, 2010 3:52 pm Post subject: Re: SETTING MAXMSGL TO 100MB |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Goodfellas wrote: |
Hello,
Do we see any MQ performance issues or impacts when we set
the MAXMSGL to 100 MB... |
Just setting MAXMSGL? No.
You will only see performance issues or impacts if you start *using* large MQ messages. Apps and MQ will need to use larger memory buffers and perform more disk i/o, require larger queue and log files, and increased network activity in proportion to the size of the messages. The MQ Performance Reports will give you an idea of what to expect.
_________________
Glenn |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Nov 24, 2010 1:15 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The question is really, for a given amount of persistent message data, will using a few large messages be less efficient than using more small ones?
I would say no overall, depending how the application processes these messages.
It will make any syncpoint have more data in a single unit of work. So if the channel was having to re-send messages due to network unreliability then it would take longer. So not ideal for slow, unreliable networks. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Nov 24, 2010 3:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
The question is really, for a given amount of persistent message data, will using a few large messages be less efficient than using more small ones?
I would say no overall, depending how the application processes these messages.
It will make any syncpoint have more data in a single unit of work. So if the channel was having to re-send messages due to network unreliability then it would take longer. So not ideal for slow, unreliable networks. |
There will most definitely be an impact. Think about a network using mostly messages < 4 MB having suddenly to process messages of 100 MB.
If your normal SLA is less than 1 sec, this change will most definitely break the SLA.
What you need to look at is to create different channels for the slow movers etc... It's all down to earth common sense.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Nov 24, 2010 3:14 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| zpat wrote: |
The question is really, for a given amount of persistent message data, will using a few large messages be less efficient than using more small ones?
I would say no overall, depending how the application processes these messages.
It will make any syncpoint have more data in a single unit of work. So if the channel was having to re-send messages due to network unreliability then it would take longer. So not ideal for slow, unreliable networks. |
Fewer larger messages will always be more efficient that more smaller messages. With fewer messages there is much less overhead wasted in processing the MQMDs, storing, marshalling and syncpointing all the messages.
These days, networks tend to be very reliable and are faster. One 1MB message will be transmitted faster than one hundred 10KB messages.
_________________
Glenn |
|
| Back to top |
|
|
|
|
