| Author |
Message
|
| bjbxd |
 Posted: Sat May 24, 2014 3:53 am Post subject: What impact for performance after increasing message size? |
 |
|
Newbie
Joined: 14 May 2014
Posts: 5
|
Hi,
My application team tell me they will use more bigger size for MQ message, average size from 1024 bytes change to 14400 bytes, I worry about how is the performance impact. We use MQ for z/OS.
Anyone have experience on this? or if there are any benchmark test data can be shared? Many thanks...
Bob. |
|
| Back to top |
|
 |
| JosephGramig |
| Posted: Tue May 27, 2014 5:34 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| There are performance reports. It all depends on what they are doing with the messages... Are there large units of work? Are these msgs going across channels? With SSL? |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Tue May 27, 2014 8:02 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Generally speaking if you need to move 14K worth of data then it is more efficient to send one 14K message than 14 1K messages.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue May 27, 2014 10:32 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Paul,
I was under the impression that MQ is optimized for moving small messages quickly, and you are better off sending more smaller messages than 1 big one. For example, its better to send 100 independent messages that are 1 MB in length instead of lumping all that data into a single 100 MB message.
True?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Tue May 27, 2014 2:39 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Hi Peter,
Yes that is true. 100MB are generally bad news for a number of reasons. Personally I would tend to advise that you try and keep messages to no bigger that 1MB if you can. Of course the exact limits change release on release which is one of the reasons it is worth looking at the performance reports. However as a general rule of thumb you are best to avoid the extremes. Don't send really small messages and don't send really big messages. The problem with small messages is really just one of CPU. It costs about the same amount of CPU to put a 1 byte message to a queue as it does to put a 10K message to a queue.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue May 27, 2014 2:52 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I'd expect to see little increase in CPU, given that z/OS is usually provisioned with lots and lots of central storage (RAM), processors
Moving 14K messages will take more I/O to disk - if messages are logged, or if messages are not consumed quickly (messages will be flushed to pagesets). z/OS usually has quite large bandwidth for DASD (disk) I/O, so I don't expect to see a dramatic increase in DASD delays with 14K messages.
_________________
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 |
|
|
| PaulClarke |
| Posted: Tue May 27, 2014 3:09 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
| Quote: |
| Moving 14K messages will take more I/O to disk |
Bruce,
I'm not sure quite what you are saying here. Surely you are not saying that one 14K message will take more I/O than 14 1K messages.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue May 27, 2014 4:01 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Nope. Sorry. I was going back to the OP, which pondered the additional workload of going from best tricks 1 k to 14k messages - on z/OS WMQ. I/O is one of zArchitecture's best tricks.
_________________
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 |
|
|
| bjbxd |
| Posted: Wed May 28, 2014 7:12 pm Post subject: |
|
|
Newbie
Joined: 14 May 2014
Posts: 5
|
Our CICS transactions on z/OS put the message into remote queue which is on AIX, yes, these msgs going across channel, without SSL.
From the performance report, the data looks ok, do you think it can be reference for our situation? thanks..
| JosephGramig wrote: |
| There are performance reports. It all depends on what they are doing with the messages... Are there large units of work? Are these msgs going across channels? With SSL? |
|
|
| Back to top |
|
|
| bjbxd |
| Posted: Wed May 28, 2014 7:14 pm Post subject: |
|
|
Newbie
Joined: 14 May 2014
Posts: 5
|
ops, not large UOW..
| bjbxd wrote: |
Our CICS transactions on z/OS put the message into remote queue which is on AIX, yes, these msgs going across channel, without SSL.
From the performance report, the data looks ok, do you think it can be reference for our situation? thanks..
| JosephGramig wrote: |
| There are performance reports. It all depends on what they are doing with the messages... Are there large units of work? Are these msgs going across channels? With SSL? |
|
|
|
| Back to top |
|
|
|
|
