Subscription performance in publish/subscribe networks

Distributed publish/subscribe in IBM MQ works by propagating knowledge of where subscriptions to different topic strings have been created in the queue manager network. This enables the queue manager on which a message is published to identify which other queue managers require a copy of the published message, to match their subscriptions.

This approach minimizes the sending of published messages to queue managers on which no matching subscriptions exist. However, the propagation of the subscription knowledge can become a significant overhead, when the number of topic strings being subscribed to is high and constantly changing through frequent subscription creation and deletion.

We can affect performance by adjusting how publications and subscriptions are flowed around your publish/subscribe network. If your network traffic has few publications, and rapid subscription creation, deletion, or change, we can stop subscription information being flowed to all queue managers, and instead forward all publications to all queue managers in the network. We can also restrict the flow of proxy subscriptions and publications for a given topic between connected queue managers, restrict the flow of proxy subscriptions containing wildcards, and reduce the number and transient nature of topic strings.

Individual subscription propagation and publish everywhere

Publish everywhere is an alternative to individual subscription propagation. With individual propagation, only publications that have a matching subscription on a queue manager are forwarded to that queue manager. With publish everywhere, all publications are forwarded to all queue managers in the network. The receiving queue managers then deliver those publications that match local subscriptions.

Individual subscription propagation

This mechanism results in the least amount of inter-queue manager publication traffic, because only those publications that match subscriptions on a queue manager are sent.

However:

• For each individual topic string that is subscribed to, a proxy subscription is sent to other queue managers in the publish/subscribe topology. The set of queue managers depends on the routing model being used, as described in Plan for distributed publish/subscribe network.
  • This messaging overhead can be significant if there are many thousands of subscriptions to create or delete (for example, recreating all non-durable subscriptions after a restart of a queue manager), or if the set of subscriptions is changing rapidly, and each is to a different topic string.
  • The number of queue managers to which the proxy subscription is propagated also affects the scale of the overhead.

• Proxy subscriptions are flowed to other queue managers using asynchronous messaging. This has the following effect:
  • There is a delay between the creation of a subscription, and the creation, delivery, and processing of the proxy subscription by the other queue managers.
  • Messages that are published at those queue managers in that interval are not delivered to the remote subscription.

Publish everywhere

With this mechanism there is no per topic string proxy subscription overhead on the system. This means that rapid subscription creation, deletion, or change does not result in increased network load and processing.

There is also no delay between creating a subscription and publications being flowed to a queue manager, because all publications are flowed to all queue managers. Therefore there is no window in which publications are not delivered to newly-created remote subscriptions.

However:

• Send all publications to all queue managers in the publish/subscribe topology, can result in excessive network traffic where publications do not have matching subscriptions on each queue manager.
  • The greater the number of queue managers in the topology, the greater the overhead.

We should consider using the publish everywhere mechanism when you expect a publication to be subscribed to from a significant proportion of our queue managers, or where the proxy subscription overheads are too great because of the frequency of subscription changes. We should use individual proxy subscription forwarding in cases where you experience increased messaging traffic when publications are sent to all queue managers, rather than to the queue managers with matching subscriptions.

We can set publish everywhere behavior at any level within the topic tree. To enable publish everywhere, you set the PROXYSUB parameter to FORCE for a high-level topic object. This results in a single wildcard proxy subscription that matches all topics below this topic object in the topic tree. When set it on a clustered topic object, the PROXYSUB(FORCE) attribute is propagated to every queue manager in the network, not just the queue manager that the topic was defined on.

Note: When used in a hierarchy, you set PROXYSUB(FORCE) individually on each queue manager, so the topology mechanism naturally limits the number of channels. However, when used in a cluster, many additional channels might be started:

• In a topic host routed cluster, channels are started from each queue manager to each topic host queue manager.
• In a direct routed cluster, channels are started from every queue manager to every other queue manager.

The overhead of starting many channels is most pronounced in a direct routed cluster, and can cause performance issues. See Direct routed publish/subscribe cluster performance.

Other ways of restricting the flow of proxy subscriptions and publications between connected queue managers

Consolidate topic strings

The use of many distinct, transient, topic strings introduces some level of management overhead on each queue manager in the system where publishers or subscriptions are attached. We should periodically assess the use of topic strings to see whether they can be consolidated. Reducing the number and transient nature of topic strings, and therefore the publishers and subscriptions to them, reduces the impact on the system.

Restrict publication and subscription scope

For a given topic, we can use the Publication scope and Subscription scope settings to keep publications and subscriptions local to the queue manager on which they are defined.

Block subscriptions made to wildcarded topics

We can restrict the flow of proxy subscriptions containing wildcards by setting the Topic attribute WILDCARD to BLOCK. See Wildcards in proxy subscriptions.

See also Balancing producers and consumers in publish/subscribe networks

Monitor proxy subscription traffic in clusters

When considering the load on the system from the proxy subscription traffic, in addition to monitoring the queues listed inBalancing producers and consumers in publish/subscribe networks, monitor the following cluster queues:

• The SYSTEM.INTER.QMGR.FANREQ queue on the subscriber queue manager.
• The SYSTEM.INTER.QMGR.CONTROL queue on all other queue managers in the cluster.

Any significant message backlog on these queues implies that either the rate of subscription change is too great for the system, or a queue manager is not correctly functioning in the cluster. If you suspect the problem lies with a specific queue manager, check that publish/subscribe support is not disabled for that queue manager. See PSMODE in ALTER QMGR. Parent topic: Tuning distributed publish/subscribe networks

Related concepts

• Direct routed publish/subscribe cluster performance
• Topic host routed publish/subscribe cluster performance
• Balancing producers and consumers in publish/subscribe networks

Related information

• Proxy subscriptions in a publish/subscribe network