| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Creating new SDR/RCVR channel to increase thoroughput |
« View previous topic :: View next topic » |
| Author |
Message
|
| zpat |
 Posted: Mon Sep 09, 2019 6:46 am Post subject: |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
If a running sender channel is mostly in substate RECEIVE this suggests network issues... correct?
Is there any difference in network confirmation behaviour when a sender channels runs out of messages to send before reaching the batch size compared to reaching the batchsize of 50 in our case?
Our sender is mostly nettime 30 millisec sometimes 200 and mostly xbatchsz 8 or 9 sometimes 50 .
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
 |
| hughson |
| Posted: Mon Sep 09, 2019 2:52 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| zpat wrote: |
| If a running sender channel is mostly in substate RECEIVE this suggests network issues... correct? |
Not necessarily. What it tells you, exactly, is that the sender is having to wait for the end of batch flow answer. While this could mean network issues, remember that it could also reflect slow discs - it's taking the receiver a long time to complete the batch; that is, to read all the messages off the network pipe, put those messages to the queue, and then commit the UoW. What you can't tell just from this SUBSTATE is whether the network pipe was full when the sender added the confirmation flow to the end of it, or whether the receiver was keeping up with the sends.
| zpat wrote: |
| Is there any difference in network confirmation behaviour when a sender channels runs out of messages to send before reaching the batch size compared to reaching the batchsize of 50 in our case? |
No.
| zpat wrote: |
| Our sender is mostly nettime 30 millisec sometimes 200 and mostly xbatchsz 8 or 9 sometimes 50 . |
I assume that the nettime 30 ms goes with the achieved batchsz of 8 or 9, and the nettime 200 goes with the achieved batchsz of 50. If this is the case, it does suggest a slow-ish network, that is the pipe is quite full and it takes the receiver a while to drain the messages from the pipe to get to the confirmation flow, since the nettime is relative to the achieved batch size.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Sep 09, 2019 3:08 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| hughson wrote: |
| zpat wrote: |
| If a running sender channel is mostly in substate RECEIVE this suggests network issues... correct? |
Not necessarily. What it tells you, exactly, is that the sender is having to wait for the end of batch flow answer. While this could mean network issues, remember that it could also reflect slow discs - it's taking the receiver a long time to complete the batch; that is, to read all the messages off the network pipe, put those messages to the queue, and then commit the UoW. What you can't tell just from this SUBSTATE is whether the network pipe was full when the sender added the confirmation flow to the end of it, or whether the receiver was keeping up with the sends.
Cheers,
Morag |
Could the sending side also be in substate RECEIVE if the receiving end of the channel is PAUSED as its going thru its Message Retries?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Sep 09, 2019 3:12 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| PeterPotkay wrote: |
| hughson wrote: |
| zpat wrote: |
| If a running sender channel is mostly in substate RECEIVE this suggests network issues... correct? |
Not necessarily. What it tells you, exactly, is that the sender is having to wait for the end of batch flow answer. While this could mean network issues, remember that it could also reflect slow discs - it's taking the receiver a long time to complete the batch; that is, to read all the messages off the network pipe, put those messages to the queue, and then commit the UoW. What you can't tell just from this SUBSTATE is whether the network pipe was full when the sender added the confirmation flow to the end of it, or whether the receiver was keeping up with the sends.
Cheers,
Morag |
Could the sending side also be in substate RECEIVE if the receiving end of the channel is PAUSED as its going thru its Message Retries? |
Yes, indeed. The sender still has to get to the end of sending it's batch, and send the confirmation flow for the batch before it goes into SUBSTATE(RECEIVE). The elongated time that it sits in SUBSTATE(RECEIVE) could be because the receiver is pausing for message retries.
You might also see it in SUBSTATE(SEND) for a longer period of time, when the receiver is pausing, because the network pipe fills and the TCP/IP send() call blocks.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Sep 09, 2019 11:43 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Thanks, I should add that all our messages are NP and we have NPMSPEED FAST.
Both ends are MQ V9 on Z OS. Internal to external 3rd party.
Does nettime include MQ processing time at the receiver end?
Would slow discs affect NPMs?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Sep 11, 2019 1:59 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| zpat wrote: |
Thanks, I should add that all our messages are NP and we have NPMSPEED FAST.
Both ends are MQ V9 on Z OS. Internal to external 3rd party.
Does nettime include MQ processing time at the receiver end?
Would slow discs affect NPMs? |
NP messages on a NPMSPEED(FAST) channel will be delivered without the use of transactions, so there is no commit call at the end of batch. This is the main factor when thinking about slow discs - the force of the disc for the commit. Thus it seems much less likely to be slow discs, and much more likely to be slow network.
NETTIME does NOT include MQ processing time at the receiver end, the receiver measures how long it took between receiving the request and answering it, and send that time period back in the answer to have it subtracted from the overall round-trip time.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| sderiis |
| Posted: Wed Oct 02, 2019 1:23 pm Post subject: |
|
|
Newbie
Joined: 02 Oct 2019
Posts: 3
|
What bandwidth is available on the physical channel? Will the new SDR/RCVR channel use the same physical channel? Or a different physical channel? (NIC card, fiber/copper cable).
Will the RCVR end be listening on the same port? Or a different port? |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Oct 03, 2019 6:56 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It will share the same infrastructure including TCP ports.
What we did find out was the other end had NOTCPTIMESTAMP set on their TCP stack.
Putting that back to the default of TCPTIMESTAMP has considerably improved matters and we are not currently seeing the very high nettime under load.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| 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
|
|
|
|
