When you design a message flow, the flexibility and richness of
the built-in nodes often means that there are several ways to achieve the
processing and therefore the end results that you require. However, you can
also find that these different solutions deliver different performance and,
if this is an important consideration, you must design for performance as
well as function.
There are two ways in which your applications can
perceive performance:
- Response time. This indicates how quickly each message is processed by
the message flow. This is particularly influenced by how you design your message
flows. This is further discussed in this topic.
- Throughput. This indicates how many messages of particular sizes can be
processed by a message flow in a given time. This is mainly affected by configuration
and system resource factors, and is therefore discussed in Optimizing message flow throughput with
other domain configuration information.
There are several aspects that influence message flow response times.
However, as you create and modify your message flow design to arrive at the
best results that meet your specific business requirements, you must 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 causes some processing overhead, so 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 overhead in the broker. There is an upper limit to the
number of nodes within a single flow. This limit is governed by system resources,
particularly the stack size.
For more information about stack sizes,
see System considerations for message flow development.
- The use of persistent and transactional messages
- Persistent messages are saved to disk during message flow processing.
This is avoided if you can specify that messages either on input, output,
or both, are non-persistent. 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 chunks of information, you might be able to improve the speed
at which they are handled by the message flow. The Large Messaging sample demonstrates
how to minimise the virtual memory requirements for the message flow to improve
a message flow's performance when processing potentially large messages.
You can find more information on improving the
performance of a message flow in this developerWorks article on message
flow performance.