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.
- 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.