Download PDF (1.3 MB) - IBM Redbooks

peak throughput, so if an adapter instance must support both high throughput for smaller
objects interspersed with occasional large objects, you must make trade-offs.
4.7.3 Tuning for maximum concurrency
For most high-volume deployments on server-class hardware, many operations present
themselves to take place simultaneously. Tuning for maximum concurrency ensures that the
server accepts enough load to saturate its core. One indication of an inadequately tuned
configuration is when additional load does not result in additional core use while the cores are
not fully used. To optimize these operations for maximum concurrency, the general guideline
is to follow the execution flow and remove bottlenecks one at a time.
Higher concurrent processing means higher resource requirements (memory and number of
threads) on the server. High concurrent processing must be balanced with other tuning
objectives, such as the handling of large objects, handling large numbers of users, and
providing good response time.
Tuning edging components for concurrency
The first step in tuning edging components for concurrency is to ensure that business objects
are handled concurrently at the edge components of Business Process Manager solutions. If
the input business objects come from the adapter, ensure that the adapter is tuned for
concurrent delivery of input messages.
If the input business objects come from WebServices export binding or direct invocation from
Java Server Pages (JSPs) or servlets, make sure the WebContainer thread pool is sized right.
For example, to allow for 100 in-flight requests to be handled concurrently by a Business
Process Manager server, the maximum size of the WebContainer thread pool must be set to
100 or larger.
If the input business objects come from messaging, you must tune the ActivationSpec (MDB
bindings) and Listener ports (WebSphere MQ or MQJMS bindings).
Tuning message-driven bean ActivationSpec properties
For each JMS export component, there is an MDB and its corresponding ActivationSpec in
the Java Naming and Directory Interface (JNDI name is module name/export component
name_AS). The default value for maxConcurrency of the JMS export MDB is 10, meaning up to
10 business objects from the JMS queue can be delivered to the MDB threads concurrently.
Change it to 100 if a concurrency of 100 is wanted.
The Tivoli Performance Viewer can be used to monitor the maxConcurrency parameter. For
each message being processed by an MDB, there is a message on the queue marked as
being locked inside a transaction (which is removed after the onMessage completes). These
messages are classed as unavailable. The PMI metric UnavailableMessageCount gives you
the number of unavailable messages on each queue point. Check this value by selecting the
resource name and then clicking SIB Service SIB Messaging Engines. Select the bus
name and click Destinations Queues.
If any queue has maxConcurrency or more unavailable messages, this condition implies that
the number of messages on the queue is currently running above the concurrency maximum
of the MDB. If this situation occurs, increase the maxConcurrency setting for that MDB.
The maximum batch size in the activation specification also has an impact on performance.
The default value is 1 (one). The maximum batch size value determines how many messages
are taken from the messaging layer and delivered to the application layer in a single step. This
batch size value does not mean that this work is done within a single transaction, and thus
64 IBM Business Process Manager V8.0 Performance Tuning and Best Practices