MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
  • 1.  Publish-Subscribe performance report (Clarification about remote and local bounding)

    Posted Thu August 25, 2022 12:00 PM
    Hi

    I would like to apply some recommendations of the Publish/Subscribe Performance report to one complex environment I manage.
    The last one I found is for MQv8 here: "https://public.dhe.ibm.com/software/integration/support/supportpacs/individual/mp0e.pdf"

    In it we see interesting statistics about peak rate. We see high difference whether or not we use client or local binding :


    My concern is that in our environment the publishing applications are all hosted in many different servers (Windows) that also host a local QM to avoid connecting directly the client application to the central remote QM.
    The central QM where all the topics and subscriptions are defined is on a central Linux MQ Server.
    So for publishing from the app to the central QM, we use a PUT to an alias queue in the local Windows QM that is pointing to an alias of a topic on the central linux QM.

    So if I refer to the tab displayed before, which row apply in our environment (type of application bindings) ? If it is local, how can I configure to use Fastpath ?

    Best regards

    Armand

    ------------------------------
    armand
    IT splecialis
    ibm
    madrid
    ------------------------------


  • 2.  RE: Publish-Subscribe performance report (Clarification about remote and local bounding)

    Posted Tue September 13, 2022 12:50 AM
    The connection mode can be found by running "dis conn(*) type(*) all"command in runmqsc.

    To run the local applications in fastpath check the following.
      https://www.ibm.com/docs/en/ibm-mq/9.2?topic=manager-connecting-queue-using-mqconnx-call

    To run channel instances associated with client applications and other channels in fastpath mode check the following.
      https://www.ibm.com/docs/en/ibm-mq/9.2?topic=management-other-things-consider-distributed-queue#q015780___q015780_1

    ------------------------------
    UMAMAHESH PONNUSWAMY
    ------------------------------



  • 3.  RE: Publish-Subscribe performance report (Clarification about remote and local bounding)

    Posted Thu September 15, 2022 04:57 AM
    Hi,
    Thanks for your answer. Very useful !
    I see how to set the trusted mode for channel in your link. But how can I make sure the channel instances are running in trusted mode ?
    (To make sure that the channel stanza file has been correctly processed for example)
    I don´t find any attribute from MQSC command DISPLAY CHANNEL that state the trusted mode.
    Regards

    ------------------------------
    armand
    IT splecialis
    ibm
    madrid
    ------------------------------



  • 4.  RE: Publish-Subscribe performance report (Clarification about remote and local bounding)

    Posted Thu September 15, 2022 05:11 AM
    Hi Armand,

    The connection(s) associated with the channel (s) display the connection type as FASTPATH if the channels are running in fastpath(trusted) mode. The command "dis conn(*) type(*) all" lists the details.

    Regards,
    mahesh

    ------------------------------
    UMAMAHESH PONNUSWAMY
    ------------------------------



  • 5.  RE: Publish-Subscribe performance report (Clarification about remote and local bounding)

    Posted Tue September 13, 2022 04:30 AM
    Edited by Paul Harris Tue September 13, 2022 08:08 AM
    In your scenario I would highly recommend setting FASTPATH for the channels (2nd link in Umamahesh's reply.), unless you are running channel exits.  We don't recommend setting local applications to FASTPATH (also know as trusted mode) as this means a bug in your application has the potential to bring the queue manager down. In your scenario it's unikely that FASTPATH applications would relieve the pinch point anyway, which is more likely to be network (and/or storage if the messages are persistent).

    If there is significant latency on the network between the queue managers you should also consider setting PipeLineLength to 2.
    https://www.ibm.com/docs/en/ibm-mq/9.2?topic=information-channels-stanza-qmini-file

    The table you refer to above is in a section looking at some base costs of Pub/Sub where a publisher is putting messages on one or more topics where there are no subscribers. I would look at some of the other scenarios in the report and use the remote client tests as indicators. Bear in mind that the numbers in the report are supposed to illustrate the differences in some scenarios. Unless your particular scenario matches one in the report very closely, you're not likely to get the same numbers.


    ------------------------------
    PAUL HARRIS
    ------------------------------



  • 6.  RE: Publish-Subscribe performance report (Clarification about remote and local bounding)

    Posted Thu September 15, 2022 05:01 AM
    Thanks Paul ! I will follow your advises.
    Best regards

    ------------------------------
    armand
    IT splecialis
    ibm
    madrid
    ------------------------------



  • 7.  RE: Publish-Subscribe performance report (Clarification about remote and local bounding)

    Posted Tue September 13, 2022 07:44 AM

    You might want to consider a test of putting a message to a queue and getting the same message using client/local/ etc to see the effect of your network.
    If you vary message size as well eg 1KB, 10 KB, 50KB, you will get a good feel of the network and how it impacts your performance.

    Colin



    ------------------------------
    Colin Paice
    ------------------------------



  • 8.  RE: Publish-Subscribe performance report (Clarification about remote and local bounding)

    Posted Thu September 15, 2022 05:03 AM
    Thanks Colin. I will make that test.
    Best regards

    ------------------------------
    armand
    IT splecialis
    ibm
    madrid
    ------------------------------



  • 9.  RE: Publish-Subscribe performance report (Clarification about remote and local bounding)

    Posted Thu September 15, 2022 06:22 AM
    You should be very careful about what you read into the performance report, or into the outome of a simple test of producing and consuming messages from singleton basic applications.
    Each environment tends to have a single most restrictive bottleneck. Using fastpath bindings makes a big difference to the CPU usage, it typically avoids two thread context switches per MQI call. If you are CPU constrained, either across the entire system (multiple concurrent threads of execution) or on a single critical application context then switching to fastpath will have a big effect. If on the other hand you were primarily network constrained, or disk constrained then it would have minimal effect.
    In order to maximize your performance you really need a good simulation of your production environment where you can measure the effect of individual changes.
    Setting MQIBindType=FASTPATH has virtually no downside in a well managed environment (one where internal MQ processes are never terminated abruptly) and so it's generally good advice to enable this option. It may make no difference to the throughput in your system, but it is very likely to reduce your CPU usage.
    I would NEVER recommend running user written applications in fastpath mode.

    I'd probably start with an analysis of whether you are predominately using persisten or non-persistent messages. If persistent then I'd make sure the IO latency is low, or the degree of application concurrency is high. If non-persistent then looking at CPU usage and whether messages are being streamed to applications (minimise TCP line turn arounds) might be more relevant, again the degree of application concurrency is likely to have a very significant bearing on the throughput.

    Applying a one size fits all approach to MQ performance tuning isn't generally a good idea.

    ------------------------------
    Andrew Hickson
    ------------------------------