A message flow includes an input node that receives a message
from an application over a particular protocol; for example, WebSphere® MQ. The message must be parsed
by the input node, and the performance impact of this parsing varies
according to the parser that is used and the number of parses required.
You can reduce the impact of parsing by using some optimization techniques
such as parsing avoidance or partial parsing. For more information
about parsing, see Parsing and message flow performance. The number
and length of message flows have implications for performance, and
it is important to keep the number of nodes to a minimum. See Message flow design and performance for more information about optimizing
message flow performance. Other aspects of processing in a message
flow that might affect performance are the amount, efficiency, and
complexity of ESQL, access to databases, and how many message tree
copies are made. For more guidance about these factors, see Code design and performance.
It is also important to consider
how you split your business logic; how much work should the application
do, and how much should the message flow do? Every interaction between
an application and a message flow involves I/O and message parsing,
and therefore adds to processing time. Design your message flows,
and design or restructure you applications, to minimize these interactions.
For more information about these factors, see Optimizing message flow response times and Optimizing message flow throughput.
The type, format, and size of the messages that are processed
can have a significant effect on the performance of a message
flow. For example, if you process persistent messages, they
must be stored for safekeeping.If you do not plan to interrogate
the structure, you can use the BLOB domain.
If you are working
with general text or binary messages, then you need to create a DFDL
(or MRM) model to describe the message. The organization of the model
can have a significant effect on performance. For fields that are
choices, are optional, or are in arrays, the model must identify
the field as efficiently as possible. Use tags (named initiators
in DFDL) if they are available. To resolve a choice, DFDL provides
a 'direct dispatch' mechanism, which avoids parsing each branch
in turn if there is a field that indicates which branch to
take. If you are using a DFDL discriminator, ensure that the
discriminator is placed so that it is evaluated as early as
possible. While regular expressions can be used to identify
and extract fields, they are generally slower than other techniques.
If
you are working in XML, be aware that it can be verbose, and
therefore produce large messages. However, XML message content
is easier to understand than other formats, such as binary fixed-length
format.
For more information about these factors, see Optimizing message flow response times and Performance
considerations for regular expressions in TDS messages.
You can create and configure one or more integration nodes, on
one or more computers, and for each integration node you can
create multiple integration servers, and multiple message flows.
Your configuration decisions can influence message flow performance,
and how efficiently messages can be processed.For more
information about these factors, see Tuning the integration node,
and Optimizing message flow throughput.