| Author |
Message
|
| HubertKleinmanns |
 Posted: Tue Aug 27, 2019 6:34 am Post subject: |
 |
|
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 |
|
 |
| bruce2359 |
| Posted: Tue Aug 27, 2019 7:28 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| hughson |
| Posted: Tue Aug 27, 2019 2:27 pm Post subject: Re: Creating new SDR/RCVR channel to increase thoroughput |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| HubertKleinmanns |
| Posted: Wed Aug 28, 2019 12:16 am Post subject: |
|
|
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 |
|
|
| ibmmqrock |
| Posted: Fri Aug 30, 2019 10:31 am Post subject: |
|
|
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 |
|
|
| HubertKleinmanns |
| Posted: Mon Sep 02, 2019 1:51 am Post subject: |
|
|
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 |
|
|
| bruce2359 |
| Posted: Mon Sep 02, 2019 5:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Sep 02, 2019 7:49 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
No one said they were.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Sep 02, 2019 8:28 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| hughson |
| Posted: Mon Sep 02, 2019 3:46 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| gbaddeley |
| Posted: Mon Sep 02, 2019 4:29 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
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 |
|
|
| bruce2359 |
| Posted: Mon Sep 02, 2019 4:33 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| bruce2359 |
| Posted: Mon Sep 02, 2019 7:37 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| hughson |
| Posted: Mon Sep 02, 2019 9:44 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| HubertKleinmanns |
| Posted: Mon Sep 02, 2019 11:59 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
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 |
|
|
|
|
