Depending on your subflow design, that is, the number of
Input nodes that you have modeled, and how you configure the overall
message flow BAR file deployment properties and the Input node deployment
properties, WebSphere® Message Broker handles threads at run time differently. This can impact your
solution performance and your message parallel processing behavior
at run time.
About this task
When you design a message flow or a subflow, you connect
message flow nodes and subflows to define the integration solution
logic. In a message flow, you use one or more Input nodes, such as
the MQinput node, to model how a message is received by the message
flow. If the first node in a message flow is a subflow, the subflow
must contain one or more Input nodes. You can also have subflows in
the middle of a message flow that include Input nodes.
When
you design a subflow that is included in a message flow and you configure
the BAR file that contains your integration solution, consider the
following questions:
- How many Input nodes, such as MQInput node, your message flow
has? How many Input nodes your subflows have?
Note: The number of
Input nodes determines the default number of threads allocated by WebSphere Message Broker to process messages.
- Have you calculated how many threads are required by WebSphere Message Broker to run your message flow?
- Are you planning to start all instances at message flow start
time? If yes, consider how many threads are allocated at start up
and what other solutions are competing for resources in your system.
- Do you have any order requirements when processing messages? If
yes, consider that an Input node can receive messages out of order,
and it will wait for the correct message to arrive before it continues
processing any messages. By adding additional instances you can cause
resource bottlenecks and not improve your solution performance.
- Does your message flow design and subflows have multiple Input
nodes? Do you need to receive messages through these Input nodes in
parallel before continuing the message flow logic? Does one of them
take longer to receive a message?
The answers to these questions will help you decide how you want
to configure your resources.
To decide which option to choose
to create additional instances, consider the following rules:
- In order to create instances which are shared between multiple
Input nodes, you must set the Additional instances property at the message flow level.
- In order to create instances which are allocated to a specific
Input node, you must set the Additional instances property at the Input node level.
In addition, you must consider the following behavior
based on how you configure additional instances:
- When you set additional instances on an Input node, the additional
instances or threads only run against that specific Input node. For
example, if you have Input node A with 15 additional instances and
Input node B with 0 additional instances, then if there is work waiting
on Queue B, it will only be processed one message at a time. The spare
instances belonging to Input node A cannot be used to process messages
received from Input node B.
- The disadvantage of setting thread pools at message flow level
is that one busy Input node could starve other input nodes.
You must decide how you want to set additional instances
based on the priority of work on different Input nodes and your subflows
and message flow design.
When you design a message flow or a subflow that includes
one or more Input nodes, you must consider the impact on resource
allocation and performance:
What to do next
Allocate additional instances at message flow level or
at Input node level. For more information, see Adding additional instances at message flow level and Adding additional instances at message flow node level.