You can use different solutions to improve message flow
response times.
About this task
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 response time indicates how quickly each message is processed
by the message flow. The response time is particularly influenced
by how you design your message flows. Response time is discussed in
this topic.
- The throughput indicates how many messages of particular sizes
can be processed by a message flow in a specified time. The throughput
is mainly affected by configuration and system resource factors, and
is discussed in Optimizing message flow throughput, with other domain
configuration information.
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 message flow statistics and accounting data 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:
- The number of nodes that you include in the message flow
- Every node increases the amount of processing required in the
integration node, therefore, consider the content of the message flow
carefully, including the use of subflows.
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 integration node.
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.
- How the message flow routes and processes messages
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.
- If your message flow includes loops
- Avoid loops of repeating nodes, which can be very inefficient
and can cause performance and stack problems. You might find that
a Compute node with multiple
PROPAGATE statements avoids the need to loop around a series of nodes.
- The efficiency of the ESQL
- Check all the ESQL code that you have created for your
message flow nodes. As you develop and test a node, you might maintain
statements that are not required when you have finalized your message
processing. You might also find that something you have coded as two
statements can be coded as one. Taking the time to review and check
your ESQL code might provide simplification and performance improvements.
- The use of persistent and transactional messages
- Persistent messages are saved to disk during message flow processing.
You can avoid this situation by specifying that messages are non-persistent
on input, output, or both. If your message flow is handling only non-persistent
messages, check the configuration of the nodes and the message flow
itself; if your messages are non-persistent, transactional support
might be unnecessary. The default configuration of some nodes enforces
transactionality; if you update these properties and redeploy the
message flow, response times might improve.
- Message size
- A larger message takes longer to process. If you can split large
messages into smaller units of information, you might be able
to improve the speed at which they are handled by the message
flow.
- Message format
- Although IBM® Integration Bus supports multiple
message formats, and provides facilities that you can use to transform
from one format to another, this transformation increases the amount
of processing required in the integration node. Make sure that you
do not perform any unnecessary conversions or transformations.
You can find more information about improving the
performance of a message flow in a developerWorks® article (developerWorks article on message flow performance).