Download PDF (1.3 MB) - IBM Redbooks

If a number of services in a FanOut section of a mediation flow exists, calling these services
synchronously results in an overall response time equal to the sum of the individual service
response times.
Calling the services asynchronously (with parallel waiting configured) results in a response
time of at least the largest individual service response time in the MFC. The response time
also includes the sum of the time taken by the MFC to process the remaining service callout
responses on the messaging engine queue.
For a FanOut/FanIn block, the processing time for any primitives before or after the service
invocations must be added in both cases.
To optimize the overall response time when calling services asynchronously in a
FanOut/FanIn section of a mediation flow, start the services in the order of expected latency
(highest latency first), if known.
You must consider the trade-off between parallelism and additional asynchronous processing.
The suitability of asynchronous processing depends on the size of the messages being
processed, the latency of the target services, the number of services being started, and any
response time requirements expressed in service level agreements (SLAs). We suggest
running performance evaluations on mediation flows, including FanOuts with high latency
services, if you are considering asynchronous invocations.
The default quality of service-on-service references is Assured Persistent. You can gain a
substantial reduction in asynchronous processing time by changing this setting to Best
Effort (non-persistent). This change eliminates I/O to the persistence store, but the
application must tolerate the possibility of lost request or response messages. This level of
reliability for the service integration bus can discard messages under load and might require
tuning.
3.2.11 Large object considerations
This section presents best practices for performance (particularly memory use) when using
large objects (LOBs). Very large objects put significant pressure on Java heap use,
particularly for 32-bit JVMs. The 64-bit JVMs are less susceptible to this issue because of the
large heap sizes that you can be configure, although throughput, response time, and overall
system performance can still be impacted by excessive memory usage. Follow these
practices to reduce the memory pressure and avoid OutOfMemory exceptions and improve
overall system performance.
Avoiding lazy cleanup of resources
Lazy cleanup of resources adds to the live set required when processing large objects. If you
can clean up any resources (for example, by dropping object references when no longer
required), do so as soon as is practical.
Avoiding tracing when processing large business objects
Tracing and logging can add significant memory resources. A typical tracing activity is to
dump the BO payload. Creating a string representation of a large BO can trigger allocation of
many large and small Java objects in the Java heap. For this reason, avoid turning on tracing
when processing large BO payloads in production environments.
42 IBM Business Process Manager V8.0 Performance Tuning and Best Practices