| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ Performance Message Max Size |
« View previous topic :: View next topic » |
| Author |
Message
|
| zpat |
 Posted: Mon Jul 20, 2009 9:26 am Post subject: |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| zpat wrote: |
| Or this buffer size could be an external referenced parameter to allow tuning without creating multiple code versions. |
QED |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Jul 20, 2009 9:31 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
I usually stick with the application design model where we don't create code to explicitly compensate for the environment (hardware, network) - as these change.
If an application requires 100meg messages, deployment should include upgrading RAM - not fiddling with app code.
_________________
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 |
|
|
| exerk |
| Posted: Mon Jul 20, 2009 9:45 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
| ...If an application requires 100meg messages, deployment should include upgrading RAM - not fiddling with app code... |
Been there, seen it, done it...it's when it's years down the line, and 'now' there is a requirement to handle that message size, but the kit can't be upgraded with anything (in the case of a particular project, RAM was on eBay for 1/10th the cost from the manufacturer because 'we don't make/supply that any more', but of course no way would they allow it in the machines), and the cost of re-hosting meant that code change was cheaper (their words, not mine!). Better to future-proof the application as far as possible was the lesson learned there...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon Jul 20, 2009 2:59 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| kevinf2349 wrote: |
| hildobiersma wrote: |
| So specify a size that's large enough, and optionally retry with a larger buffer, but don't specify an MQGET buffer size of 10MB if your messages are going to be 20K. |
I must be missing something here.
If your buffer is 10Mb and you get a 20K message only 20K is retrieved so why would that lead to a performance issue? |
When a user application does an MQGET, one of the MQ processes (I don't remember which - amqzlaa0?) also attempts to allocate memory, based on the requested buffer size. Aside from the issue of allocating more memory than necessary, for really large buffer sizes this can fail with an MQRC=2102 (resource problem). Would that be considered a performance issue? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 20, 2009 3:13 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...MQRC=2102 (resource problem). Would that be considered a performance issue |
?
I suppose... technically no; but I'm sure it would fall under a missed SLA.
_________________
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: Mon Jul 20, 2009 4:01 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Quote: |
| Aside from the issue of allocating more memory than necessary, for really large buffer sizes this can fail with an MQRC=2102 (resource problem). Would that be considered a performance issue? |
No, it would be considered a capacity issue.
_________________
Glenn |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
