| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| sender channel too slow |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Mon Nov 07, 2005 11:17 am Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
OK, knowing that, I guess I can read between the lines of the manual and see that's what you need to do. It should be clearer.
Anyway,any guess as to whether I need Low, Medium or High to just get some NETTIME #s?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| hopsala |
| Posted: Mon Nov 07, 2005 11:50 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| mquseless wrote: |
| There is no attribute BATCHTMR; perhaps hopsala was referring to BATCHINT |
I was indeed, a typo.
| mquseless wrote: |
| BATCHSZ cannot make any difference if the xmitq is filling up - there will be more than BATCHSZ msgs in the xmitq already. |
I'm afraid you're mistaken - the reason that the queue is filling up is that messages are being transferred too slowly, and if these are large msgs or a large number of msgs, BATCHSZ will increase chl throughput dramatically. I will note, however, that if the bottleneck is the network itself, I agree it will be of no use.
Read up performance support pacs, or try it yourself, this is performance improvement feature is prevalent throughout WMQ literature; aside from the fact I have used it myself a hundred times and more... |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Nov 07, 2005 12:02 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
A "meta"-typo:
| Quote: |
| I was indeed, a typo. |
_________________
-wayne |
|
| Back to top |
|
|
| hopsala |
| Posted: Mon Nov 07, 2005 12:16 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Sheesh, can't I do anything right? Correction: "I was indeed; a typo."
Now that that's settled, I can crawl into a dark corner and die in shame. |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Nov 07, 2005 12:22 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
It's funny hopsala, I thought you meant:
| Quote: |
| "It was indeed a typo." |
_________________
-wayne |
|
| Back to top |
|
|
| ramires |
| Posted: Mon Nov 07, 2005 1:33 pm Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
You also can try implment channel pipelinning.
Regards |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Nov 08, 2005 2:13 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
as hopsala wrote before, messages can pile up BECAUSE batchsize is too small. with higher batchsize (in combination with batchint) you save commits and improve the throughput of the channel
_________________
Regards, Butcher |
|
| Back to top |
|
|
| ramires |
| Posted: Tue Nov 08, 2005 2:31 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
Ech time a batch ends, both queue managers have go trough a syncpoint protocol. If the BATCHSZ increases the number of times this syncpoint procotol is called is reduced.
Regards |
|
| Back to top |
|
|
| wschutz |
| Posted: Tue Nov 08, 2005 2:46 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
We should also remember that, on the receiving end, none of the messages become available to applications until the batch is complete and commited. So if you have really large batches moving really large messages, it might take a while before the first message in the batch becomes available.
_________________
-wayne |
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Tue Nov 08, 2005 4:33 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
Well, if you transmit many messages (lets say 500.000 a day for example) over the same channel, then the number of commits at the default BATCHSZ of 50, is at least 10000.
I don't know what the time is we are talking about for commiting. But I think this is major..
No, I should say I know it is major. Because I have experimented around with it.
And even IBM will tell you on the MQAdminII training, that BATCHSZ does matter as hell if talking about performance.
As the original post explains, network speed is not a problem. The 1st answer that would pop into ones brain would be the BATCHSZ.
So yes, it might be the same old answer. But what is wrong with it, if it is still a very valid point? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Nov 08, 2005 4:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| mquseless wrote: |
Do you guys actually know what you are talking about from first principles?
It seems to me that you are just recycling the same old answers without taking account of the reported symptoms. |
You suggested adding more channels as a solution.
I asked for more clarification on how to do this...
Because it seems to me this answer has already been discussed and dismissed.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Nov 08, 2005 4:50 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
@mquseless
| Quote: |
| What has BATCHINT got to do with it? This attribute determines how long to wait after the xmitq has become empty for another msg to arrive on the xmitq to send. Surely this will slow down the channel, not speed it up.... |
.
there are many attributes that affect the channel speed and performance, so do batchint and batchsize.
lets assume your batchsize is 25, but batchint is 0, and a message is put to the xmitq every 1/10 second, what will happen? if the channel is fast you will send 10 messages per second with 10 commits. now, if you add batchint and wait - lets say 0,2 second, you will only have half of the commits.
to give a real example: we have a queuemanager sending about 200 to 600 messages per second using 100 sender channels. batchsize was 25, batchint was 0. the average batchsize (computed from the channel status) was 1.2, so i hat 5 commits for 6 messages.
i asked the application if i was allowed to add some "delay" to the messages, and yes, i was allowed to use 0,15 seconds batchint - saving me 66% of all commits, and - in total - 10% of the cpu time of this queuemanager (and remember - this will save also cpu at the remote end).
whether this slows down the channel - well, it depends. of course the messages will arrive later than witthout wait, on the other hand mq is less busy with commits, so more cpu is available for the application. if the application is not that fast then it does no make a big difference. if you want to go realtime with the fastest responsetime possible, then yes, use batchsz 1 and batchint 0.
| Quote: |
| , and anyway has nothing to do with this problem because in this case the channel is moving msgs too slowly and therefore the xmitq is never emptying, and so BATCHINT has not effect whatsoever |
if messages pile up, the question is "why do they pile up", not "how to i get rid of the already piled up messages", and a bad batchint / batchsz setting is one possible reason for that (beside many others).
you always say "because in this case the channel is moving msgs too slowly", but i ask "WHY is it moving that slow"? and "can it be tuned"? And from my experience BATCHINT and BATCHSZ can help tuning the channel.
_________________
Regards, Butcher
Last edited by Mr Butcher on Tue Nov 08, 2005 5:54 am; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Nov 08, 2005 8:28 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Mr Butcher wrote: |
| if you want to go realtime with the fastest responsetime possible, then yes, use batchsz 1 and batchint 0. |
be careful, it will improve response time for the messages that would have made the front of the previously larger batch, but may very well dealy the later ones.
Example: 100 messages a second are going over a channel. Batch Size is 100. Every 100 messages, we do one commit. Message #1 is delayed by syncpoint for 1 second, whereas message #100 is delayed only by the time of the commit.
In this scenario, you drop Batch Size to 1. Now there are 100 commits for that 100 messages. True, the first few messages are now available in less than a second, performance improved, but maybe, just maybe all that overhead of the commits now means the channel can only move 75 messages a second. All of the sudden you get a log jam building up where there was previously no problem.
Consider this line of thinking as it relates to the original problem, and it is *possible* that upping the batch size will help. Then again, it may not, as the delay is not caused by waiting for too many commits, but by something else (slow network, slow CPU, putting app is taking to long to do ITS commits, etc)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Nov 09, 2005 12:06 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
yes, thats true. this sentence was related to a single message / response. it always depends what you want to archieve... fast responses, maximum throughput or something in between....... depending on the needs of the application.
_________________
Regards, Butcher |
|
| 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
|
|
|
|
