WebSphere Message Brokers
File: ac00355_
Writer: Karen Cameron

Task topic

This build: July 31, 2007 21:16:29

Optimizing message flow response times

This topic describes how you can improve message flow response times.

Before you start:
Read the following concept topic:

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.

Your applications can perceive performance in either of these ways:

  1. 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.
  2. The throughput indicates how many messages of particular sizes can be processed by a message flow in a given time. The throughput is mainly affected by configuration and system resource factors, and is discussed in the topic on optimizing message flow throughput along with other domain configuration information. See Optimizing message flow throughput.

Several aspects 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. The number of nodes within a single flow has an upper limit. This limit is governed by system resources, particularly the stack size.

For more information about stack sizes, see System considerations 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. For example, if you want to define some specific processing based on the value of a field in each message, you might design a message flow that has a sequence of Filter nodes to handle each case. If appropriate, you can group messages through the Filter node to reduce the number that each message type has to pass through before being processed.

For example, you might have a message flow that handles eight different messages (Invoice, Despatch Note, and so on). You can include a Filter node to identify each type of message and route it according to its type. You can optimize the performance of this technique by testing for the most frequent message types in the earliest Filter nodes. However, the eighth message type must always pass through eight Filter nodes.

If you can group the message types (for example, if the message type is numeric, and you can test for all types greater than four and not greater than four), you can reduce the number of Filter nodes required. The first Filter node tests for greater than four, and passes the message on to two further Filter nodes (attached to the true and false terminals) that test for less than two and less than six respectively. An additional four Filter nodes can then test for one or two, three or four, and so on. Although the actual number of Filter nodes required is the same, the number of nodes that each message passes through is reduced.

You might find that using a RouteToLabel node with a set of Label nodes provides a better alternative to a sequence of Filter nodes. Each message passes through a smaller number of nodes, improving throughput. However, you must also consider using a RouteToLabel node means using a Compute node: the overhead of this node might outweigh the advantages. If you are dealing with a limited number of message types, a small number of Filter nodes is more efficient.

The following sample demonstrates how you can use the RouteToLabel and Label nodes instead of using multiple Filter nodes in the XML_PassengerQuery message flow. The following sample demonstrates how you can store routing information in a database table in an in-memory cache in the message flow. You can view samples only when you use the information center that is integrated with the Message Brokers Toolkit.
If your message flow includes loops
Avoid loops of repeating nodes; these 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 round 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.

If you have imported message flows from a previous release, check your ESQL statements against the ESQL available in Version 5.0 to see if you can use new functions or statements to improve its efficiency.

The use of persistent and transactional messages
Persistent messages are saved to disk during message flow processing. This situation 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 following sample demonstrates how to minimize the virtual memory requirements for the message flow to improve a message flow's performance when processing potentially large messages. You can view samples only when you use the information center that is integrated with the Message Brokers Toolkit.
Message format
Although WebSphere Message Broker supports multiple message formats, and provides facilities that you can use to transform from one format to another, this incurs overhead. Make sure that you do not perform any unnecessary conversions or transformations.

You can find more information on improving the performance of a message flow in this developerWorks article on message flow performance.

Related concepts
Message flows overview
Deployment overview
System considerations for message flow development
Related tasks
Configuring WebSphere Message Broker
Optimizing message flow throughput
Designing a message flow
Using more than one input node
Creating a message flow
Defining message flow content
Editing configurable properties
Related reference
Built-in nodes
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:16:29

ac00355_ This topic's URL is: