Each message flow that you design must provide a complete set of processing for messages received from a certain source. This design might result in very complex message flows that include large numbers of nodes that can cause a performance overhead, and might create potential bottlenecks. You can increase the number of message flows that process your messages to provide the opportunity for parallel processing and therefore improved throughput.
You can also consider the way in which the actions taken by the message flow are committed, and the order in which messages are processed.
Consider the following options for optimizing message flow throughput:
You can update the Additional Instances property of the deployed message flow in the BAR file: the broker starts additional copies of the message flow on separate threads, providing parallel processing. This option is the most efficient way of handling this situation, if you are not concerned about the order in which messages are processed.
If the message flow receives messages from a WebSphere MQ queue, you can influence the order in which messages are processed by setting the Order Mode property of the MQInput node:
For publish/subscribe applications that communicate with the broker over any supported protocol, messages for any given topic are published by brokers in the same order as they are received from publishers (subject to reordering based on message priority, if applicable). Therefore each subscriber receives messages from a particular broker, on a particular topic, from a particular publisher, in the order that they are published by that publisher.
However, it is possible for messages, occasionally, to be delivered out of order. This situation can happen, for example, if a link in the network fails and subsequent messages are routed by another link.
If you need to ensure the order in which messages are received, you can use either the SeqNum (sequence number) or PubTime (publish time stamp) parameter on the Publish command for each published message, to calculate the order of publishing.
For more information about the techniques recommended for
all MQI and AMI users, see the Application Programming Reference and Application
Programming Guide sections in the WebSphere MQ Version 6 information center
online or
(for WebSphere MQ Version 5.3) the Application
Programming Guide and Application Programming Reference books
from the WebSphere MQ
library Web page for
programs written to the MQI, and the WebSphere MQ Application Messaging Interface book
for programs written to the AMI.
The WebSphere MQ Application Messaging Interface book is available from the WebSphere MQ library Web page (listed under Version 5.3), or from SupportPac™ MA0F on the WebSphere MQ SupportPacs Web page.
See also the Publish/Subscribe User's Guide section
in the WebSphere MQ Version 6 information center
online or
(for WebSphere MQ Version 5.3) the Publish/Subscribe
User's Guide from the WebSphere MQ
library Web page.
WebSphere MQ Everyplace® and SCADA applications use a different method of message ordering as described in WebSphere MQ Mobile Transport and WebSphere MQ Telemetry Transport. The broker does not provide message ordering for messages received across WebSphere MQ Web Services Transport, WebSphere MQ Real-time Transport, or WebSphere MQ Multicast Transport.
This option also removes the ability to determine the order in which the messages are processed, because, if there is more than one copy of the message flow active in the broker, each copy can be processing a message at the same time, from the same queue. The time taken to process a message might vary, and multiple message flows accessing the same queue might therefore read messages from the input source in a random order. The order of messages produced by the message flows might not correspond to the order of the original messages.
Ensure that the applications that receive message from these message flows can tolerate out-of-order messages.
The following two examples show when you might want to split a message flow:
You might also need to provide another input queue and input node to complete any common processing that the Label node branches connect to when unique processing has been done.
You can also create a new message flow that replicates the function of the original message flow, but only processes large messages that are immediately passed on to it by the original message flow, that you modified to check the input message size and redirect the large messages.
The following properties control the frequency with which the message flow commits transactions: