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 » IBM MQ Installation/Configuration Support » Choice of using Standard Bindings vs Fastpath bindings

Post new topic  Reply to topic
 Choice of using Standard Bindings vs Fastpath bindings « View previous topic :: View next topic » 
Author Message
czech77
PostPosted: Sat May 07, 2022 7:49 pm    Post subject: Choice of using Standard Bindings vs Fastpath bindings Reply with quote

Newbie

Joined: 07 May 2022
Posts: 5

I have gone through over 20 posts on this forum on Standard vs Fastpath bindings and they were excellent, but there is one question I need some information about!

Our MQ (We are currently on 9.2.0.2 and it's an Appliance) handles millions of messages today along with some applications with large files. We currently have Fastpath bindings configured and it was all fine until a recent P1 incident bringing our QMGR down due to huge pile up of messages on SYSTEM CLUSTER TRANSMIT QUEUE. Upon analyzing it, the root cause has been identified to amqrmppa process and one of the suggestions that came out (apart from others such as applying the latest fix pack 9.2.0.5 etc.,) was to use Standard Bindings over the existing Fastpath bindings.

I understand that there is some performance trade-off with Standard Bindings but I do not have a datapoint on what that trade-off would be? Is there any documentation or performance analysis report or any other metric that gives me a view of what that trade-off would look like? We need to make a decision quickly with this choice. I appreciate your inputs and suggestions in this regard.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sun May 08, 2022 7:02 am    Post subject: Reply with quote

Poobah

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

You’ve omitted the ProbeId, error message, APAR number, which might help us here. amqrmppa is the reciever-side MCA (Message Channel Agent).

Way back in old and slow single or dual processor days, running MQ channels as trusted could improve performance (a few percentage points). The well-documented risks and restrictions still apply today, although the benefits in todays blisteringly fast multi-processor environment have substantially minimized the performance benefits - while the risks remain.
_________________
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: Sun May 08, 2022 7:59 am    Post subject: Reply with quote

Poobah

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

Moved to Installation/Configuration Support forum.
_________________
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: Sun May 08, 2022 10:03 pm    Post subject: Reply with quote

Padawan

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

The question over whether one should use FASTPATH bindings or not was always, as I recall anyway, about whether you could trust the code running in the same process as the queue manager agent. Since you are on the MQ Appliance, you cannot have any user code in the system, i.e. no channel exits, so there would seem to be nothing that isn't trust-worthy IBM code. This would normally be an excellent choice for FASTPATH.

Who was it that suggested to you to stop using FASTPATH and what was their reasoning?

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
czech77
PostPosted: Mon May 09, 2022 12:11 am    Post subject: Reply with quote

Newbie

Joined: 07 May 2022
Posts: 5

hughson wrote:

Who was it that suggested to you to stop using FASTPATH and what was their reasoning?

Cheers,
Morag


You absolutely makes sense when you describe how the choice of bindings shouldn't affect the MQ on Appliance. I'm surprised that this suggestion is coming from IBM Distinguished Engineer (DE) from Hursley Labs and his exact words are quoted below:

------ Reply from IBM Labs---------
Yes in summary, the MQ Labs are strongly advising you move to the latest FixPack (9.2.0.5) to pick up the identified APAR IT36729 as well as a number of others in the same area. This should mean you do not encounter the same Memory Error which caused the amqrmppa process to Fail.

The recommendation to move to Standard Bindings over Fastpath Bindings is to restrict the potential impact of any future issues to the amqrmppa process to that process only and not create the same Failure Scenario all be it for a different issue with the amqrmppa process.

Hope that helps clarify things, please let us know how you will be looking to progress ?
Thanks and regards ... Adrian (for Bob).
----- End of the Reply from IBM Labs----------
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon May 09, 2022 2:10 am    Post subject: Reply with quote

Poobah

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

Sarcasm?

Will you be applying the recommended corrective service?

https://www.ibm.com/support/pages/apar/IT36729?mhsrc=ibmsearch_a&mhq=IT36729
_________________
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
czech77
PostPosted: Mon May 09, 2022 11:17 pm    Post subject: Reply with quote

Newbie

Joined: 07 May 2022
Posts: 5

bruce2359 wrote:
Sarcasm?

Will you be applying the recommended corrective service?

https://www.ibm.com/support/pages/apar/IT36729?mhsrc=ibmsearch_a&mhq=IT36729


Yes, we plan to apply 9.2.0.5 which also has the Fix you mentioned above. My question still remains on the choice of bindings (Standard vs Fastpath) though! I'll update this thread post our call with IBM Hursley Labs person later, for everybody's benefit.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue May 10, 2022 3:35 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

hughson wrote:
The question over whether one should use FASTPATH bindings or not was always, as I recall anyway, about whether you could trust the code running in the same process as the queue manager agent. Since you are on the MQ Appliance, you cannot have any user code in the system, i.e. no channel exits, so there would seem to be nothing that isn't trust-worthy IBM code. This would normally be an excellent choice for FASTPATH.

And yet IBM decided its better to ship the appliance without the defaults being FASTPATH.


czech77, did you guys do a performance comparison between using Standard vs Fastpath bindings? If yes, was the difference relevant and worth the additional risk? Relevant because lets says it reduced the latency by 50% (wow, how great!!!). But oh wait, its 1 microsecond instead of 2 microseconds, so while technically 50% less latency, not noticeable and thus irrelevant. I don't know the actual performance lift (if any), just using that as an example. You may be chasing irrelevant performance gains at the cost of real risk to stability.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
hughson
PostPosted: Tue May 10, 2022 8:12 pm    Post subject: Reply with quote

Padawan

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

PeterPotkay wrote:
hughson wrote:
The question over whether one should use FASTPATH bindings or not was always, as I recall anyway, about whether you could trust the code running in the same process as the queue manager agent. Since you are on the MQ Appliance, you cannot have any user code in the system, i.e. no channel exits, so there would seem to be nothing that isn't trust-worthy IBM code. This would normally be an excellent choice for FASTPATH.

And yet IBM decided its better to ship the appliance without the defaults being FASTPATH.

Is that true Peter? I had been under the impression that the default on the Appliance was indeed FASTPATH?

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: Wed May 11, 2022 5:40 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

hughson wrote:
PeterPotkay wrote:
hughson wrote:
The question over whether one should use FASTPATH bindings or not was always, as I recall anyway, about whether you could trust the code running in the same process as the queue manager agent. Since you are on the MQ Appliance, you cannot have any user code in the system, i.e. no channel exits, so there would seem to be nothing that isn't trust-worthy IBM code. This would normally be an excellent choice for FASTPATH.

And yet IBM decided its better to ship the appliance without the defaults being FASTPATH.

Is that true Peter? I had been under the impression that the default on the Appliance was indeed FASTPATH?

Cheers,
Morag


I don't know! Don't have access to an MQ Appliance.

I ASSumed it was defaulted to standard. I inferred it was defaulted to standard if IBM is telling czech77 to not use FastPath. I mean, why would IBM ship something with a default setting they don't want customers to use.

But I admit, I don't know what the MQ Appliance's default is for Fastpath versus Standard.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
dware
PostPosted: Wed May 11, 2022 5:41 am    Post subject: Reply with quote

Novice

Joined: 18 Nov 2013
Posts: 13

I can confirm that fastpath is the default for the MQ Appliance.

On the original question, regarding fastpath performance for channels, it definitely can make a difference to overall message throughput (not just latency), although it will depend on the scenario. The most benefit would likely be seen in CPU intensive scenarios, for example, client connected, non-persistent messaging applications, although benefits across persistent scenarios have also been seen. You'd really need to test your style of workload to understand the relative impact and whether that's acceptable in your situation.

In the case of the MQ Appliance, there is no possibility of user code. This is why fastpath channels are enabled by default in that environment. I would expect the original suggestion to disable fastpath channels on the appliance would have been predominantly as a temporary measure, to mitigate the risk from the known MQ problem that had been identified in the version that was running. With the fix applied, that risk would be removed.

The fact that this situation arose shows that there are never zero implications to running fastpath channels, even without exits in the picture. But then, as we all know, that’s true for any piece of logic. So it’s a constant balance of levels of protection versus performance. MQ believes that when no external code is in the equation, fastpath channels make sense for the benefits it brings in performance. However, the option to be more cautious, for the sake of reduced top-end performance, is still available to you.

It’s probably worth saying that any situation where fastpath is causing a problem with MQ-only channel logic, is treated as a product defect and IBM would obviously work to resolve it.

David Ware
IBM MQ
Back to top
View user's profile Send private message
Andyh
PostPosted: Wed May 11, 2022 10:58 am    Post subject: Reply with quote

Master

Joined: 29 Jul 2010
Posts: 237

There are also very significant memory consumption savings in using fastpath bindings for channels, particularly where large numbers of clients are attached.

MQ supports 4 types of MQI binding:
1. Client
2. Isolated
3. Shared (aka standard)
4. Fastpath.

With client bindings and isolated binding there is no writable shared memory attached in the 'application' process and hence no matter how badly a client or isolated bound application might behave it cannot damage any other MQ process through overwriting MQ shared memory.

Both shared and fastpath biound processes run the risk that a badly behaved process could overwrite memory shared with other MQ processes potentially leading to a wider queue manger scope issue.

Fastpath bound applications access the most shared state and additionally can execute blocks of code in which MQ cannot tolerate a failure. Any failure in one of these "must complete" blocks would be detected and result in the queue manager aborting. When a heavily multi-threaded process exits abruptly and any thread of that process was executing in one of these must complete blocks the queue manager will terminate abruptly (with no loss of persistent message integrity). Thus the risk of running badly behaved 'applications' in fastpath mode is thus higher than of running those applications in shared bindings mode.

The queue manager treats an amqrmppa process much like any other multi-threaded application in this regard, except that the amqrmppa can ONLY use shared or fastpath binding. Thus a badly behaved amqrmppa (APARable in the absence of any user code (i.e exits)) always implies some risk of an abrupt QM termination. Given that a positive identification of such an APARable issue has been made it is important that the customter applies the appropriate fix, either through applying current service, or by applying the ciorrect specific fix.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » Choice of using Standard Bindings vs Fastpath bindings
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.