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 Index » General IBM MQ Support » Creating new SDR/RCVR channel to increase thoroughput

Post new topic  Reply to topic Goto page 1, 2, 3  Next
 Creating new SDR/RCVR channel to increase thoroughput « View previous topic :: View next topic » 
Author Message
ibmmqrock
PostPosted: Thu Aug 15, 2019 5:19 am    Post subject: Creating new SDR/RCVR channel to increase thoroughput Reply with quote

Novice

Joined: 30 May 2019
Posts: 14

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.

Any opinions here?
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Aug 15, 2019 5:29 am    Post subject: Reply with quote

Poobah

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

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?

What has your performance team done to capture channel stats, and model the proposed new configuration?
_________________
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
ibmmqrock
PostPosted: Thu Aug 15, 2019 5:53 am    Post subject: Reply with quote

Novice

Joined: 30 May 2019
Posts: 14

Hi bruce, thank you for replying.

Quote:
NIC card, fiber/copper cable).

These values will remains the same for new SDR/RCVR channel pair.

Quote:
Will the RCVR end be listening on the same port? Or a different port?
It would be listening to same port.

Quote:
What has your performance team done to capture channel stats, and model the proposed new configuration?

the NETTIME of SDR channel is (68336, 68789) which is on higher end. that is why I am worried if other applications on-board, it may cause congestion on this channel.
Back to top
View user's profile Send private message
HubertKleinmanns
PostPosted: Thu Aug 15, 2019 5:55 am    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

Hi,

could could also think about separating the message flows, e. g.:

- online channel / batch channel (separate small and fast from big and slow)

- by customer (customer with lot's of big messages don't affect customers with a few or small messages)
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
ibmmqrock
PostPosted: Thu Aug 15, 2019 6:17 am    Post subject: Reply with quote

Novice

Joined: 30 May 2019
Posts: 14

HubertKleinmanns wrote:
Hi,

could could also think about separating the message flows, e. g.:

- online channel / batch channel (separate small and fast from big and slow)

- by customer (customer with lot's of big messages don't affect customers with a few or small messages)

Thanks for suggestion, we don't have Batch interfaces, also the messages size are same across all applications and it is pretty small, only concern is the volume of messages, the new application which is coming on-board has around 80K messages per day.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Aug 15, 2019 6:19 am    Post subject: Reply with quote

Poobah

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

ibmmqrock wrote:
the NETTIME of SDR channel is (68336, 68789) which is on higher end. that is why I am worried if other applications on-board, it may cause congestion on this channel.

Ok, what is XQTIME? That's time on transmission queue? That's wait time in the xmit queue before messages are transmitted.

Are your apps missing SLA's? If so, is the cause network delay? Or, something else?

I asked about network bandwidth. Is this network saturated? Or, is there bandwidth available?

How many messages per second will the new app be creating?
_________________
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
Vitor
PostPosted: Thu Aug 15, 2019 6:26 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

If you don't currently use message priority, you might want to start, or create a new channel pair so you can have high and low business importance messages on two channels.

Don't forget:

- by creating a new channel pair you'll have 2 MCAs handling message transmission so twice the horsepower moving messages (and as this is z/OS you can be granular about which get the most resources)

- once you saturate the network pipe you're done
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
HubertKleinmanns
PostPosted: Thu Aug 15, 2019 6:32 am    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

Another remark: Just creating a second channel is not very helpful. You also have to split the data:

- Create a second xmitQ

- Change half of the remote Queues to use this new XmitQ

So you would make a "load balancing by hand".

A sender channel opens the XmitQ exclusively and so this cannot be used by a second channel.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
hughson
PostPosted: Thu Aug 15, 2019 4:19 pm    Post subject: Reply with quote

Padawan

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

ibmmqrock wrote:
only concern is the volume of messages, the new application which is coming on-board has around 80K messages per day.

So what achieved batch sizes are you getting on your channel today? Are you moving full batches now or not?

Look at DISPLAY CHSTATUS and either take the number of MSGS and the number of BATCHES and divide one into the other to see the approximate number of messages you get per batch, or if you have MONCHL turned on, look at the XBATCHSZ number where the channel keeps track of it for you.

If you're not already running lots of full batches, you might find an improvement in your overall throughput!

As others have said, you need to be able to answer the question about whether this channel is already saturated with its current load to know whether adding the additional load will cause issues.

Other questions to ask are whether there are specific SLA requirements on the current messages. If today for example you are actually only achieving batches of one message, and then you add load so that each batch is full of 50 messages, how does that change the SLA on message number 1 in the batch. If it is a persistent message, it will not be available until 49 more messages have been sent. If it is non-persistent it is available immediately. You don't mention your message persistence in any of your posts so I don't know if this is relevant to you.

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: Thu Aug 15, 2019 4:56 pm    Post subject: Reply with quote

Jedi

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

If you are concerned about capacity or contention on a SDR/RCVR channel, you should collect statistics on current usage and estimate what the new app will be using. If you have a volume test or QA environment, you can replicate the current and new app, and observe the performance.

MQ will basically use all available resource capacity (disk, CPU, memory, network) to transport messages as fast as possible. You should identify if there are any constraining resources that affect the performance requirements. Its quite possible that there will be no noticeable effect on app performance.
_________________
Glenn
Back to top
View user's profile Send private message
ibmmqrock
PostPosted: Tue Aug 27, 2019 5:51 am    Post subject: Reply with quote

Novice

Joined: 30 May 2019
Posts: 14

Quote:
hughson wrote:
ibmmqrock wrote:
only concern is the volume of messages, the new application which is coming on-board has around 80K messages per day.

So what achieved batch sizes are you getting on your channel today? Are you moving full batches now or not?

Look at DISPLAY CHSTATUS and either take the number of MSGS and the number of BATCHES and divide one into the other to see the approximate number of messages you get per batch, or if you have MONCHL turned on, look at the XBATCHSZ number where the channel keeps track of it for you.

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

Quote:
hughson wrote:

If you're not already running lots of full batches, you might find an improvement in your overall throughput!

Our batch Size is 50 and Batch Interval is 0, we don't get too many messages so that is why probably we only use Batch as 1.

As others have said, you need to be able to answer the question about whether this channel is already saturated with its current load to know whether adding the additional load will cause issues.
hughson wrote:

Other questions to ask are whether there are specific SLA requirements on the current messages. If today for example you are actually only achieving batches of one message, and then you add load so that each batch is full of 50 messages, how does that change the SLA on message number 1 in the batch. If it is a persistent message, it will not be available until 49 more messages have been sent. If it is non-persistent it is available immediately. You don't mention your message persistence in any of your posts so I don't know if this is relevant to you.

Well, we have some application sending Persistent messages and some are not. so that is why I didn't focus on Persistent of applications.
Cheers,
Morag
Back to top
View user's profile Send private message
ibmmqrock
PostPosted: Tue Aug 27, 2019 5:59 am    Post subject: Reply with quote

Novice

Joined: 30 May 2019
Posts: 14

Vitor wrote:
If you don't currently use message priority, you might want to start, or create a new channel pair so you can have high and low business importance messages on two channels.


Our applications doesn't specify any message priority for the messages.

Don't forget:
Vitor wrote:

- by creating a new channel pair you'll have 2 MCAs handling message transmission so twice the horsepower moving messages (and as this is z/OS you can be granular about which get the most resources)

well, we don't have any priority over the applications or channels, just looking for the idea to increase throughput by splitting channels/XMITQ
- once you saturate the network pipe you're done
Back to top
View user's profile Send private message
ibmmqrock
PostPosted: Tue Aug 27, 2019 6:00 am    Post subject: Reply with quote

Novice

Joined: 30 May 2019
Posts: 14

HubertKleinmanns wrote:
Another remark: Just creating a second channel is not very helpful. You also have to split the data:

- Create a second xmitQ

- Change half of the remote Queues to use this new XmitQ

So you would make a "load balancing by hand".

A sender channel opens the XmitQ exclusively and so this cannot be used by a second channel.


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.
Back to top
View user's profile Send private message
HubertKleinmanns
PostPosted: Tue Aug 27, 2019 6:23 am    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

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.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Tue Aug 27, 2019 6:26 am    Post subject: Reply with quote

Poobah

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

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.

How do you intend to measure the before/after in order to scientifically validate that your changes had the effect you want?
_________________
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
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2, 3  Next Page 1 of 3

MQSeries.net Forum Index » General IBM MQ Support » Creating 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.