| Author |
Message
|
| ibmmqrock |
 Posted: Thu Aug 15, 2019 5:19 am Post subject: Creating new SDR/RCVR channel to increase thoroughput |
 |
|
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 |
|
 |
| bruce2359 |
| Posted: Thu Aug 15, 2019 5:29 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| ibmmqrock |
| Posted: Thu Aug 15, 2019 5:53 am Post subject: |
|
|
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 |
|
|
| HubertKleinmanns |
| Posted: Thu Aug 15, 2019 5:55 am Post subject: |
|
|
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 |
|
|
| ibmmqrock |
| Posted: Thu Aug 15, 2019 6:17 am Post subject: |
|
|
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 |
|
|
| bruce2359 |
| Posted: Thu Aug 15, 2019 6:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| Vitor |
| Posted: Thu Aug 15, 2019 6:26 am Post subject: |
|
|
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 |
|
|
| HubertKleinmanns |
| Posted: Thu Aug 15, 2019 6:32 am Post subject: |
|
|
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 |
|
|
| hughson |
| Posted: Thu Aug 15, 2019 4:19 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| gbaddeley |
| Posted: Thu Aug 15, 2019 4:56 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
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 |
|
|
| ibmmqrock |
| Posted: Tue Aug 27, 2019 5:51 am Post subject: |
|
|
Novice
Joined: 30 May 2019
Posts: 14
|
| Quote: |
| 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 |
|
|
| ibmmqrock |
| Posted: Tue Aug 27, 2019 5:59 am Post subject: |
|
|
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 |
|
|
| ibmmqrock |
| Posted: Tue Aug 27, 2019 6:00 am Post subject: |
|
|
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 |
|
|
| HubertKleinmanns |
| Posted: Tue Aug 27, 2019 6:23 am Post subject: |
|
|
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 |
|
|
| bruce2359 |
| Posted: Tue Aug 27, 2019 6:26 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
|
|
