Throughput

In WebSphere MQ Publish/Subscribe, a single thread processes publications on each of the stream queues. This guarantees the order in which publications are processed from the queue.

When you consider throughput for publications in a WebSphere Message Broker broker domain, you must also consider the importance of the order in which messages are published. Techniques that increase throughput do not necessarily guarantee order.

WebSphere Message Broker supports two options that increase throughput:
  1. You can configure the message flow with additional threads by setting the Additional Instances property of the MQInput node. This property causes the broker to schedule additional threads to read messages from the input queue, thus allowing publications from that queue to be processed concurrently by the broker. You must ensure that the stream (input) queue has the share attribute set (WebSphere MQ Publish/Subscribe required stream queues to have noshare set).

    If multiple threads process messages from a single queue, publications are not guaranteed to be delivered to subscribers in the order in which they are placed on the input queue. However, WebSphere Message Broker provides a method of allowing publications to be processed concurrently, while still maintaining the required sequence.

    Set the Order Mode property of the MQInput node to the value By User ID. This ensures the order of delivery of publications sent to the broker by a given user. When this property is set, the processing of messages that carry a given UserIdentifier field in the MQMD is held up if any other thread servicing that message flow is currently processing a message that carries the same UserIdentifier.

    The benefits of running additional instances of the message flow are negated if all publishing applications are running under the same user ID. This might be the case for publishing applications connected to a queue manager remote to the broker's queue manager. Messages from these remote publishers arrive at the broker on a channel that might have been set up to insert the channel program's user ID instead of the originating client's user ID. Refer to the WebSphere MQ Intercommunications book for more information about how to set the PUTAUT channel attribute to change the default channel behavior.

  2. You can configure one or more additional message flows (not instances) that read publications from different queues. You must also update some of your publishing applications to publish to the new queue (or queues). This has the effect of splitting the stream, and therefore spreading the workload.

    If you decide to increase throughput using this method, you must consider the impact this has on the order in which publications are delivered. In particular, you must ensure that the publisher applications are split with respect to the topics they are publishing to ensure that order can be maintained for each topic, if this is important. If your applications publish to different queues (message flows) on the same topic, order cannot be guaranteed.

    If you update the publisher applications to send publications to a new queue that has a name different from the stream on which they are publishing, you must also update these applications to explicitly include the stream name within their publications using the MQPSStreamName parameter.

    Publishing applications that specify a stream parameter do not need to be modified, as this parameter takes precedence. However, if publishing applications do not specify the stream parameter, the behavior is determined by the setting of the Implicit Stream Naming property of the publication node in the message flow:
    • If the property is set to false, the default stream is assumed.
    • If the property is set to true, the stream name is assumed to be the same as the name of the stream input queue.