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.
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.
- Providing sufficient threads to maximize
the throughput of messages.
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.
- To be able to view 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.
- 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.
- 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.
- Tuning the messaging engine data store (not required for Cloudscape).
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. Finally,
save your changes to the master configuration.
- Using a remote DB2 Universal Database.
By default,
messaging engines are configured to use Cloudscape as the underlying data
store database. Changing to a DB2 database, especially a remote database,
significantly improves performance. This is of particular benefit on systems
with more than two CPUs. A remote DB2 database provides a 50% higher throughput
than a local DB2 database, for the same total (application server plus database)
CPU utilization.
- 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. For the relative performance
of the different reliability levels, see the WebSphere Application Server
performance report.
- 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.