| Author |
Message
|
| JAdams |
 Posted: Mon Jul 29, 2002 6:42 am Post subject: Large messages vs many small messages |
 |
|
Apprentice
Joined: 11 Jul 2002
Posts: 47
Location: Lakeland, FL
|
Hello,
Currently we tend to use small messages (150 bytes to 16k) in our MQSeries environment. As part of our EAI initiative we are planning on moving to very large messages (up to 40-50 meg). One reason for this is to eliminate message affinities.
I have read the Performance and Tuning support pac. It does cover the increase in CPU utilization as the message size increases. What it does not show is a comparison of an application using a single large message (20 meg) vs a similar application using many smaller messages (20000).
Does anyone have experience with using large messages compared to smaller ones? Is there a difference in the impact to the network for distributed messaging? Any advice regarding this issue would be appreciated.
Jason |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Mon Jul 29, 2002 8:19 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
We did some testing on larger vs smaller and found that the bigger message performed better. Some of the reasons are:
1) The MQ Headers take 300-500 bytes
2) If you have the resources to read in 1 20mb message with 1 MQGET
That save processing versus 20 1mb MQGETS and all the logic te reassemble it.
It has been awhile so I dont recall any exact numbers, I dont have access to the info anymore(Former Employeer)
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| bduncan |
| Posted: Mon Jul 29, 2002 10:17 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I've had the same experience, but I've seemed to misplace all the colorful excel charts I created to illustrate this.
Another point:
Let's say you have 20,000 1K messages versus 1 20Mb message. Since you mention the reason for using 1 big message over many small ones is to get rid of affinity, then I would assume that you would retrieve the 20,000 messages by matching against CorrelId, MsgId, etc.... This matching requires a linear search through the queue. As the depth of the queue increases, so does the search time - lowering your throughput, which could in turn cause the queue depth to increase even more - a vicious cycle which could ultimately bring down your queue manager. Therefore, if your queues typically have high depths - 10s of thousands to 100s of thousands, then it makes sense to compress them into fewer large messages since this will cut down on the search times related to MQGETs. Of course, if you are able to remove affinities altogether by using larger messages, then you completely remove this issue...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| mqonnet |
| Posted: Tue Jul 30, 2002 7:27 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Brandon/Jeff,
I partially agree to your comments, and would like to get inputs on my thoughts.
I think there should be a balance between large and small messages & the number of such messages. Performance wise i agree to your comments, but you also need to consider the fact that Recovery in the event of a disaster becomes much difficult and expensive(since the logs would occupy lot of space as checkpointing is after long periods of time and also size). Which also suggests that you could easily cross limits set for the logs. All of these only if you are using persistent messages, which is what i assume if you are going for large messages. As large messages NPM does not have any significance, per my understanding.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Jul 30, 2002 7:43 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
I gather from his question that he has x amount of data to send and would it be better suited to send 1 big message or 10 smaller messages to equal x. So actually I beleive that fewer messages would lower some of the logging requirements because of the reduced number of syncpointed messages(Just a theory on this part.) Which in turn also may
reduce cpu cycles.
As for NPM SPEED (Non Persisten Message) is only for Non-Persistant message size is not the issue. Well the only issue with this that comes up
is the Queue Ram Buffer by default it is 64kb so if you exceed that the message will be written to the disk, however if you tune this value higher
then you also send bigger messages that will not be written to disk.
Iam not sure of the maximum Queue buffer size is.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Jul 30, 2002 7:46 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I agree with mrlinux. If I'm trying to move a certain amount of data from queue manager A to queue manager B, the logging requirements should be about the same no matter how I decide to carve up that amount of data. Presumably I'll be issuing my MQCMIT after that chunk of data is moved, not after a certain number of messages is moved. So the commit will happen at the same time regardless of the number of messages that comprised my unit of work.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| mqonnet |
| Posted: Tue Jul 30, 2002 7:56 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Well, i think we both were on the wrong side of the track in understanding what the original problem was. My post was with the assumption that the app is putting/getting from a single QM. Not sure what the original post was pointing to, but for discussion sake can we consider this scenario and discuss my previous post. I would still go with my statements.
Now coming to the case Jeff mentioned, i still think sending smaller messages would be safer compared to larger ones. We should not consider just the "all is well" environment when designing a system. And hence, we must consider that if you are trying to send large messages accross QM's, the probability of errors are a plenty compared to the other way round. There are so many dependencies, MCA should behave fine on both ends, the checkpointing of message should be appropriate at the other end, network is not ill-behaved, Transaction should hold good(and not expire) as it usually does in the case of pretty large messages.
Hence, i would go with trying to balance between Large/Small and the number of messages rather than going all out for large messages, smaller in number.
Please comment.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Jul 30, 2002 8:06 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
If your are trying to bring network errors (resending packets) into the picture the packets that are resent are not the whole message just the missed or packets with errors and since packet size on the ethernet networks I have worked with is 1500 bytes that doesnt amount to much.
However smaller doesnt mean fewer packets
For this example lets say between TCP/IP/MQ headers we use 500 bytes
(makes the math easy) using 1500 bytes as the packet size
if we send 2 1001 byte message it will go into 4 packets
if we send 1 2002 byte message it will 2 into 2 packets.
(remember that with one message you only get 1 MQ header so the second packet will get at least an extra 300 bytes.)
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Jul 30, 2002 10:12 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I still don't understand why there should be a distinction in log sizes between large and small messages.
If I mean to send a 1 Mb file from one queue manager to another, I'm obviously going to want the entire operation to happen within a single unit of work. If the operation involved more than one MQCMIT, then you could have the situation where only part of the file made it across. So whether I ultimately send that file as 1000 1Kb messages or 1 1Mb message, I'm still doing a single unit of work, encapsulating 1 Mb of data, with a single MQCMIT at the end. Assuming overhead (message headers, etc) is negligible - the log is going to require 1Mb of space in either case.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Jul 30, 2002 10:21 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
bduncan,
I agree that the log is size is not going to very much for the amount of
data that is sent. I was just pointing smaller data sizes dont mean that the
network will send them with less network packets.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| mqonnet |
| Posted: Tue Jul 30, 2002 11:15 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Ok, let me clear a few things so that we all are on the same code page.
I still don't understand why there should be a distinction in log sizes between large and small messages.
---Well, there isn't. Because in either cases, you would always predefine/set the size of log files.
If I mean to send a 1 Mb file from one queue manager to another, I'm obviously going to want the entire operation to happen within a single unit of work. If the operation involved more than one MQCMIT, then you could have the situation where only part of the file made it across. So whether I ultimately send that file as 1000 1Kb messages or 1 1Mb message, I'm still doing a single unit of work, encapsulating 1 Mb of data, with a single MQCMIT at the end. Assuming overhead (message headers, etc) is negligible - the log is going to require 1Mb of space in either case.
---You are absolutely right here. But this was not my question which i wanted opinions on.
I know and agree that in the scenario you described above, logs have no impact what so ever. But i am still going with the original question and the scenario of recrovery in the case of a disaster. Let me explain in detail.
Say you are given a task to design/architect a system. The consideration here is to put/get send/retrieve messages from a Qm. You have two options, either design in such a way that you have smaller messages large in number or large messages smaller in number. What i have been upto in all my posts is that, you need to have a trade off between the two, you cannot just choose one and neglect the other. Here's the reason why.
-> Smaller messages give more performance as opposed to larger ones. Hence the cpu, qm and apps are all happy. In the event of a disaster, you can very well, recover all the messages, since the checkpointing is at regular intervals(size of messages being small). Hence all is well. The only drawback here is, that the app has to do many more MQI calls than larger messages, also the QM is always kept busy.
-> Larger messages are always a very attractive option, because you can dump everything all at once. But what we must bear in mind is that, in the event of a disaster, it is hard to recover such messages. Reason, the checkpointing is done only at the end of a transaction. And if there was a failure say at a point where you put 99% of a large message. Since the transaction did not complete, the message is not commited and hence is not retrieveable. Which means, you have no other option but to resend the whole thing all over again. Remember in the case of smaller messages, since the size is small, this is not a real overhead.
Jeff
I agree that the log is size is not going to very much for the amount of
data that is sent. I was just pointing smaller data sizes dont mean that the
network will send them with less network packets
->I think i did not put myself right. I never meant the gory details of networking in my post. My point of view has always been of recovery. And if you have messages flowing accross QM's, recovery is as difficult as the case i explained above.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| JAdams |
| Posted: Wed Jul 31, 2002 7:47 am Post subject: |
|
|
Apprentice
Joined: 11 Jul 2002
Posts: 47
Location: Lakeland, FL
|
Wow...looks like I sparked a stream of good converstation. To give some more background I will be passing persistent messages between my OS/390 platform and an MQSeries Hub server (NT) which are both located in the our data center. Network outage is virtually a non-issue, so is bandwith. Client applications and our broker connect to the hub.
Looks like I can't go wrong using the large messages. All of you have provided some valuable input. Thank you! 
Jason |
|
| Back to top |
|
|
| mrlinux |
| Posted: Wed Jul 31, 2002 8:14 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
If you send the 1 mb file 1k msg at a time and you have to recover you will still need to resend the whole thing, due to the fact you have not commited the messages to the queue. So writing 1mb message and commiting is probaly faster than writing 1000 1k msgs with 1 commit.
If the message isnt commited on the queue you will lose it and wont be able to recover it.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed Jul 31, 2002 8:26 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Right.. that's what I was attempting to point out... If the queue manager goes down on the 1000/1000 message, when it recovers the 999 I did send will automatically be rolled back, because there is no way to recover that unit of work. I can't simply send the 1000th message and issue a commit. I still need to send all 1000 over again...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| mrlinux |
| Posted: Wed Jul 31, 2002 8:51 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Two more things to add
1) Bigger messages actually use less CPU cycles.
Also related to this is BMC Producted for compress messages,
according to there pitch you can save enough CPU cycles
compressing the messages to pay for there product on the mainframe
150k.
2) If the 1 MQPUT fails with the big message you have to retry
If the MQPUT fails with the smaller message you have to retry,
However it has been my expeirnce that MQSeries rarely fails
MQPUT with resource issues. The only ones I have seen are
are Queue Space Full (This is ibm limit on the q size file), and
MQSeries Storage issues (reason code 2071) and this one is due
to a kernel limit and the multi-threaded nature of the MQAgents.
So with a 99% Success rate and the only 2 issues I have had would still
of cause problems with smaller messages why would I want to slow the
stuff down.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
|
|
