ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportCreating new SDR/RCVR channel to increase thoroughput

Post new topicReply to topic Goto page Previous  1, 2, 3
Creating new SDR/RCVR channel to increase thoroughput View previous topic :: View next topic
Author Message
zpat
PostPosted: Mon Sep 09, 2019 6:46 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5673
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
View user's profile Send private message
hughson
PostPosted: Mon Sep 09, 2019 2:52 pm Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1220
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
View user's profile Send private message Visit poster's website
PeterPotkay
PostPosted: Mon Sep 09, 2019 3:08 pm Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7554

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
View user's profile Send private message
hughson
PostPosted: Mon Sep 09, 2019 3:12 pm Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1220
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
View user's profile Send private message Visit poster's website
zpat
PostPosted: Mon Sep 09, 2019 11:43 pm Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5673
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
View user's profile Send private message
hughson
PostPosted: Wed Sep 11, 2019 1:59 am Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1220
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
View user's profile Send private message Visit poster's website
Display posts from previous:
Post new topicReply to topic Goto page Previous  1, 2, 3 Page 3 of 3

MQSeries.net Forum IndexGeneral IBM MQ SupportCreating new SDR/RCVR channel to increase thoroughput
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.