Use this task to set tuning properties that control the performance
of message-driven beans and other messaging applications deployed to use service
integration technologies.
About this task
To optimize the performance of messaging with service integration
technologies, such as message-driven beans that use the default messaging
provider, you can use the following parameters set through the WebSphere administrative
console or command line interfaces.
On z/OS, the performance
of messaging applications is affected by the number of servants, which can
vary dynamically, and the distribution of work between servants. For more
information about configuring and managing the number of servants and the
distribution of work between servants, see Tuning the application serving environment.
- Viewing the Available Message Count on a
destination enables you to determine whether your message consumers are able
to cope with your current workload. If the available message count on a given
destination is too high, or is increasing over time, you should consider some
of the tuning recommendations on this page.
- To monitor the available message count for a queue, you need
to enable runtime AvailableMessageCount statistics for the queue. If you restart
administrative server, you need to enable AvailableMessageCount statistics
again because such runtime settings are not preserved when the server is restarted.
To enable AvailableMessageCount statistics using the administrative
console, complete the following steps:
- In the navigation pane, click
- In the content pane, click server_name
- Click the Runtime tab.
- In the Currently monitored statistic set, click Custom
- On the Custom monitoring level panel, click messageEngine_namequeue_name
- Select the AvailableMessageCount option.
- Click the Enable button at the top of the panel.
- To view the available message count, you can use the administrative
console to complete the following steps:
- In the navigation pane, click
- In the content pane, click server_name
- Click messageEngine_namequeue_name
- Click the View Module(s) button at the top of the
Resource Selection panel, located on the left side. This displays the AvailableMessageCount
data in the Data Monitoring panel, located on the right side.
You can use
the Data Monitoring panel to manage the collection of monitoring data; for
example, you can use the buttons to start or stop logging, or to change the
data displayed as either a table or graph.
- Monitoring MDB Thread Pool Size for the Default Message Provider.
You may experience a performance bottleneck if there are insufficient threads
available for the Message Driven Beans. There is a trade-off between
providing sufficient threads to maximize the throughput of messages and configuring
excessive threads, which can lead to CPU starvation of the threads in the
application server. If you notice that the throughput for express nonpersistent,
reliable nonpersistent, or reliable persistent messaging has fallen as a result
of increasing the size of the default thread pool, then you should decrease
the size of the thread pool and reassess the message throughput.
- By default MDBs use the default thread pool. To view or change
the number of threads in the default thread pool for an application server,
you can use the administrative console to complete the following steps:
- In the navigation pane, click
- In the content pane, click server_name
- Under Additional properties, click . By default the Minimum size
value is set to 5 and the Maximum size value is set to 20. The best performance
is obtained by setting the Maximum size value to the expected maximum concurrency
for all message-driven beans. For high throughput using a single message-driven
bean, 41 was found to be the optimal Maximum size value.
- To change the Maximum size value, type the new value
in the Maximum size field then click OK. Finally, save
your changes to the master configuration.
- As the default thread pool is also used by other WAS components
it can be beneficial to define a separate thread pool for the MDBs. This will
reduce thread contention for the default thread pool. To create your own thread
pool you can use the administrative console to complete the following steps:
- In the navigation pane, click
- In the content pane, click server_name
- Under Additional properties, click . Create a new thread pool. Create sufficient threads to support
the maximum amount of concurrent work for the MDBs.
- b. Change the SIB JMS Resource Adapter to use the
new thread pool: Resources -> Resource Adapters -> Resource
Adapters.
- Open Preferences and select the SIB
JMS Resource Adapter with the appropriate scope depending upon
the scope of the connection factories. Add the name of the new thread pool
in the Thread pool alias box. Click Apply and
save the changes.
- Tuning MDB performance with the default messaging provider.
- The maximum concurrent endpoints parameter controls the amount
of concurrent work that can be processed by an MDB. The parameter is applicable
to MDBs using an activation specification. Increasing the number of concurrent
endpoints can improve performance but can increase the number of threads in
use at one time. To benefit from a change in this parameter, there should
be sufficient threads available in the MDB thread pool to support the concurrent
work. If message ordering must be retained across failed deliveries this parameter
should be set to 1. This parameter can be set from the administrative console:
- Click on Resources -> JMS -> Activation
Specification.
- 2. Delivering batches of messages to each MDB endpoint can improve
performance particularly when used with Acknowledge mode set to Duplicates-ok
auto-acknowledge. This parameter is applicable to MDBs using an activation
specification. If message-ordering must be retained across failed deliveries,
the batch size should be set to 1. This parameter can be set from the administrative
console:
- Click on Resources -> JMS -> Activation
Specification.
For additional information about tuning the throttling of message-driven
beans, including controlling the maximum number of instances of each message-driven
bean and the message batch size for serial delivery, see Configuring MDB throttling on the default messaging provider.
- Reducing the number of OutOfCacheSpace errors in the SystemOut.log
file.
OutOfCacheSpace errors in the SystemOut.log file indicate
that the discardable data buffer used by the messaging engine is overflowing.
For best effort nonpersistent messages, the messaging engine starts to discard
messages when this buffer is full. You can increase the size of this data
buffer to allow more best effort nonpersistent data to be handled before the
messaging engine begins to discard the messages.
For more information
about tuning the size of the discardable data buffer, set by the sib.msgstore.discardableDataBufferSize
property of a messaging engine, see Controlling the memory buffers used by a messaging engine.
- Reducing the occurrence of OutOfMemoryError exceptions when processing
a large set of messages within a transaction. If the cumulative
size of the set of messages being processed within a transaction by the service
integration bus is large enough to exhaust the JVM heap, OutOfMemoryError
exceptions occur. Consider one of the following options:
- Increase the heap size for the Java Virtual Machine (JVM) used by
the WebSphere Application Server by setting the Initial Heap Size and Maximum
Heap Size properties of the application server. To view the administrative
console page, click . For more information
about changing the JVM configuration for the application server, see Java virtual machine settings.
- Reduce the cumulative size of the set of messages being processed
within the transaction.
- Changing the maximum connections in a Connection Factory for the
default messaging provider. The maximum connections parameter
limits the number of local connections. The default is 10. This parameter
should be set to a number equal to or greater than the number of threads (enterprise
beans) concurrently sending messages. Using the administrative
console you can set the Maximum connections property as follows:
- Click on Resources -> JMS -> Topic
Connection Factory -> factory_name -> Connection
pool properties
- Enter the required value in the Maximum connections field.
- Click Apply and save the changes to master configurations.
- Tuning the messaging engine message stores
- Additional tuning advice for a messaging engine using a JDBC data
source.
To improve the performance of messaging throughput of
a messaging engine data store, you can tune the JDBC connection pool and statement
cache size. In tests of high throughput MDB workloads, the following changes
provided a 10% gain in throughput.
- The messaging engine uses a connection pool for managing the
JDBC connections to its data store. Tuning the size of the pool can improve
the messaging throughput.
To view or change the size of the
connection pool, you can use the administrative console to complete the following
steps:
- In the navigation pane, click
- In the content pane, click jdbc_provider_name
- Under Additional properties, click data_source_name
- Under Additional properties, click Connection pool properties
- View the Maximum connections property and the Minimum connections property.
By default, these properties are set to Maximum connections=10 and Minimum
connections=1. Setting the value of both these properties to 50 is recommended.
For especially high throughput workloads, setting the value of both these
properties up to 100 can be beneficial. You may need to configure the underlying
database to accept this many concurrent connections.
- To change the value of a property, type a new value
in the property field then click OK. Finally, save
your changes to the master configuration.
- The statement cache contains recently used prepared statements
to remove the costs associated with repeated preparation of statements. Tuning
the size of the cache helps prevent useful entries from being discarded to
make room for new entries.
To view or change the size of the
statement cache, you can use the administrative console to complete the following
steps:
- In the navigation pane, click
- In the content pane, click jdbc_provider_name
- Under Additional properties, click data_source_name
- Under Additional properties, click WebSphere Application Server
data source properties
- View the Statement cache size property. By default, the value of this
property is set to 10. For high throughput JMS messaging, a value of 40 is
recommended.
- To change the value of the property, type a new
value in the property field then click OK. Save your changes to the master configuration.
- Tuning reliability levels for messages.
The reliability
level chosen for the messages has a significant impact on performance. In
order of decreasing performance (fastest first), the reliability levels are:
Best-Effort Nonpersistent, Express Nonpersistent, Reliable Nonpersistent,
Reliable Persistent, and Assured Persistent. For MDB point-to-point messaging,
best-effort nonpersistent throughput is more than 6 times greater than assured
persistent.
For more information about reliability levels, see Message reliability levels.
- Tuning MDB performance with the default messaging
provider.
For information about tuning the throttling of message-driven
beans, including controlling the maximum number of instances of each message-driven
bean and the message batch size for serial delivery, see Configuring MDB throttling on the default messaging provider.