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  Next
Creating new SDR/RCVR channel to increase thoroughput View previous topic :: View next topic
Author Message
HubertKleinmanns
PostPosted: Tue Aug 27, 2019 6:34 am Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

ibmmqrock wrote:
Hi, yes the idea is to create a separate XMITQ and changing RemoteQ definitions for those applications.
I hope I can achieve a better throughput with this.


As gbaddeley mentioned earlier, MQ uses the resources ot the system and is very effective. You should optimize the channel derfinitions first and measure the effect. If you really have a problem with the network throughput you should think about channel compression.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Tue Aug 27, 2019 7:28 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

... provided your server has sufficient processor availability and compression hardware.
_________________
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
View user's profile Send private message
hughson
PostPosted: Tue Aug 27, 2019 2:27 pm Post subject: Re: Creating new SDR/RCVR channel to increase thoroughput Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

I've come back to your original question again just to be sure I'm answering the question you need answered.

ibmmqrock wrote:
We have SDR/RCVR channel between Mainframe & Unix server and this channel is being used couple of applications.

You've told us in your later remarks that this current channel is very lightly loaded, achieving barely more that one message per batch (even though BATCHSZ(50)) and not utilising BATCHINT. It moves a mixture of persistent and non-persistent messages.

ibmmqrock wrote:
we now have new applications coming on board and earlier the plan was to use the same SDR/RCVR but we are also worried it may decrease the throughput of that channel.

One thing you haven't yet mentioned is any figures to describe the load these new applications will add to the channel. Also the persistence of these new messages.

ibmmqrock wrote:
I don't think creating a new SDR/RCVR channel pair will help in thoroughput or not as the QMGRs and hence ports are same.

Unless you are planning to add so many messages that you saturate the channel, it is unlikely to be necessary to add a second pair.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software


Last edited by hughson on Wed Aug 28, 2019 12:30 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
HubertKleinmanns
PostPosted: Wed Aug 28, 2019 12:16 am Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

bruce2359 wrote:
... provided your server has sufficient processor availability and compression hardware.


of course .

And it's neccessary, to measure the throughput from end to end, to find out, if compression wins or looses performance.

But as Morag mentionend in her last post, the channel seems to be very lightly loaded and I don't see any Performance issues too.


ibmmqrock,

what issue do you really have?
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
ibmmqrock
PostPosted: Fri Aug 30, 2019 10:31 am Post subject: Reply with quote

Novice

Joined: 30 May 2019
Posts: 14

HubertKleinmanns wrote:
ibmmqrock wrote:
Hi Morag, Yes we have monitoring enabled and whenver I check the XBATCHSZ , it is always 1. But I did divide the MSGS with the Batches and I got a count of 1.07


I assume that XBATCHSZ is integer. It contains a Long term and a short term value.

A value of "1" could mean:

1. The DISCINT interval is lower than the interval between to PUTS.

2. The BATCHSZ is set to "1".

In the first case increase the DISCINT value on both ends of the channel.

In the second case increase the BATCHSZ on both ends of the channel.

None of the above is true, the DISCINT is 3600 whereas batch size is 50

How did you came to conclusion on above 2 points?
Back to top
View user's profile Send private message
HubertKleinmanns
PostPosted: Mon Sep 02, 2019 1:51 am Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

Your initial question was:

ibmmqrock wrote:
I think I already know answer to this but would like to get opinions of experts here.

We have SDR/RCVR channel between Mainframe & Unix server and this channel is being used couple of applications.

we now have new applications coming on board and earlier the plan was to use the same SDR/RCVR but we are also worried it may decrease the throughput of that channel.

I don't think creating a new SDR/RCVR channel pair will help in thoroughput or not as the QMGRs and hence ports are same.


So my interpretation was, that you have some channel performance issues.

In a later reply you wrote

ibmmqrock wrote:
whenver I check the XBATCHSZ , it is always 1.


My assumption of having BATCHSZ set to 1 was because of a value of 1 for XBATCHSZ (on a heavy loaded channel).

Now you wrote

ibmmqrock wrote:
the DISCINT is 3600 whereas batch size is 50


This means you channel is far away from being busy. You are thinking about creating more channel pairs - why? A heavy loaded channel would have a value close to 50 for XBATCHSZ.

I'm now pretty sure, that adding additional channel pairs would not increase your all-over performance. Channels need some resources for its own (memory, CPU). So I would expect, that many idle channels would need much more resources than one busy channel.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Mon Sep 02, 2019 5:39 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

“idle” and “busy” aren’t valid channel states according to https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.con.doc/q015610_.htm
_________________
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
View user's profile Send private message
PeterPotkay
PostPosted: Mon Sep 02, 2019 7:49 am Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

bruce2359 wrote:
“idle” and “busy” aren’t valid channel states according to https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.con.doc/q015610_.htm

No one said they were.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon Sep 02, 2019 8:28 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

Ok. "idle" and "busy" are imprecise in this context.
_________________
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
View user's profile Send private message
hughson
PostPosted: Mon Sep 02, 2019 3:46 pm Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

bruce2359 wrote:
Ok. "idle" and "busy" are imprecise in this context.

Much about performance can appear to be imprecise.

"Idle" would generally mean, "sending very little, to no, data". This is more precisely articulated by the fact that, although BATCHSZ is set to 50 on the channel, the achieved batch size is 1. This shows that the channel has messages to deliver that arrive with enough time between them to mean that a new batch is made for each message. This is one definition of lightly loaded.

Another way to more precisely measure "Idle" would be to show that heartbeat flows are happening, because they happen when no messages flow for the entire duration of the heartbeat interval. This was not discussed as part of the channel described in this thread.

"Busy" is of course even harder to define, but in the case of this thread, "not busy" was inferred by the above lightly loaded channel.

Hope that helps.
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
gbaddeley
PostPosted: Mon Sep 02, 2019 4:29 pm Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

hughson wrote:
... "Busy" is of course even harder to define, but in the case of this thread, "not busy" was inferred by the above lightly loaded channel....

Hi Morag,
Agree, but messages per batch is not necessarily an indicator of busy. Busy can just mean "normal workload".
Bytes Sent per second is a good measure, as it can be compared to network utilisation, a common resource constraint.
Quite often the source app can't drive MQ hard enough to reach any limits or cause any contention on channels.
_________________
Glenn
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon Sep 02, 2019 4:33 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

The batch size to be used is negotiated when a channel starts, and the lower of the two channel definitions is taken.
_________________
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
View user's profile Send private message
bruce2359
PostPosted: Mon Sep 02, 2019 7:37 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

gbaddeley wrote:
Quite often the source app can't drive MQ hard enough to reach any limits or cause any contention on channels.

If he M/F is the sender end, it can exceed mid-range resources capability to keep up. One message per batch can impose needless delays if more messages are ready-to-send.

To the OP: How do you intend the 2nd sdr-rcvr channel be configured differently from the current one?
_________________
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
View user's profile Send private message
hughson
PostPosted: Mon Sep 02, 2019 9:44 pm Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

bruce2359 wrote:
The batch size to be used is negotiated when a channel starts, and the lower of the two channel definitions is taken.

Please don't confuse the negotiated batch size (which is this case was 50) with the achieved batch size (which in this case was 1).

Even if a channel negotiates to use a batch size of 50, it will close the batch and send it when it reaches the "empty-transmission-queue" state and exceeds the interval defined in BATCHINT (and of course in more recent versions of MQ takes into account BATCHLIM). That was what was happening in the OP's channel - messages were not coming along frequently enough, and so the batches were being closed before they were full.

This is one definition of "not busy" and why a number of people on this thread have advised the OP that it is unlikely he needs a second channel.

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
HubertKleinmanns
PostPosted: Mon Sep 02, 2019 11:59 pm Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

bruce2359 wrote:
“idle” and “busy” aren’t valid channel states according to https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.con.doc/q015610_.htm


Nice that these two words lead to a lively discussion .

I thought, my intention was quite clear .

I meant:

- idle - only a few messages pass the channel - the XmitQ is mostly empty.

- busy - lots of messages pass the channel - the XmitQ is mostly not-empty.

I know, these aren't really channel states, but just a rough circumscription of the channel performance.

Sorry about my nebulous wording .
_________________
Regards
Hubert
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  Next Page 2 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.