You can use different solutions to improve message flow response times.
When you design a message flow, the flexibility and functional capabilities of the built-in nodes often mean that there are several ways to achieve the processing and results that you require. You might find that different solutions deliver different levels of performance and, if performance is an important consideration for you, take it into account when designing your message flow
Your applications can perceive performance in either of these ways:
The web user interface enables you to view message flow statistics and accounting data, including the message flow throughput and the CPU and elapsed times for transactions in the flow. See Viewing accounting and statistics data in the web user interface for more information about how you can access the statistical data.
Several aspects influence message flow response times. However, as you create and modify your message flow design to arrive at the best results for your specific business requirements, also consider the eventual complexity of the message flow. The most efficient message flows are not necessarily the easiest to understand and maintain; experiment with the solutions available to arrive at the best balance for your needs.
Several factors influence message flow response times:
Use as few nodes as possible in a message flow; every node that you include in the message flow increases the amount of processing required in the broker. The number of nodes in a single flow has an upper limit, which is governed by system resources, particularly the stack size. For more information about stack sizes, see System resources for message flow development.
In some situations, you might find that the built-in nodes, and perhaps other nodes that are available in your system, provide more than one way of providing the same function. Choose the simplest configuration. Where a message flow is required to process more than a single type of record, you can create an easily extendible framework by developing a message flow structure in which there is a parse of the message to determine the type, followed by a RouteToLabel node and Label nodes for each of the types. Where a higher number of label nodes is expected, consider implementing the message parse and Label selection in one message flow, and the processing of each of the label types into separate message flows. The interface between these two flows would be through a queue.
You can view information about samples only when you use the product documentation that is integrated with the IBM® Integration Toolkit or the online product documentation. You can run samples only when you use the product documentation that is integrated with the IBM Integration Toolkit.
You can view information about samples only when you use the product documentation that is integrated with the IBM Integration Toolkit or the online product documentation. You can run samples only when you use the product documentation that is integrated with the IBM Integration Toolkit.
You can find more information about improving the performance of a message flow in a developerWorks® article (developerWorks article on message flow performance).