To help optimize performance, you can 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, you can use the administrative console to set various parameters
as described in the steps below. You can also set these parameters by using the
wsadmin tool.
-
View the Available Message Count on a destination.
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, consider some of the tuning recommendations in
this topic.
-
Enable AvailableMessageCount statistics for a queue.
If you restart the administrative server, enable AvailableMessageCount
statistics again because such runtime settings are not preserved when the
server is restarted.
- 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
.
- Select the AvailableMessageCount option.
- Click Enable at the top of the panel.
-
View the available message count for a queue.
- In the navigation pane, click
.
- In the content pane, click
server_name
.
- Click
.
- Click View Module(s) 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.
-
Monitor MDB Thread Pool Size for the Default Message Provider.
You might 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
too many 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 decrease the size
of the thread pool and reassess the message throughput.
-
View or change the number of threads in the default thread pool
for an application server.
By default, message-driven beans use
the default thread pool.
- 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 bean, 41 was found to be the optimal Maximum
size value.
- Change the Maximum size value, then click OK.
- Optional:
Create your own thread pool.
The
default thread pool is also used by other
WebSphere® Application Server components,
so you might want to define a separate thread pool for the message-driven
beans. This reduces thread contention for the default thread pool.
- Click
.
- Create a new thread pool.
- Create sufficient threads to support the maximum amount of concurrent
work for the message-driven beans.
- Change the SIB JMS Resource Adapter to use the new thread pool:
- Click
.
- If you cannot see any SIB JMS Resource Adapter instances in the list,
expand Preferences and enable Show built-in
resources.
- 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 .
-
Save your changes to the master configuration.
-
Tune MDB performance with the default messaging provider.
-
Click
.
-
Set the maximum batch size for this activation specification.
Delivering batches of messages to each MDB endpoint can improve performance,
particularly when used with Acknowledge mode set to Duplicates-ok
auto-acknowledge. However, if message ordering must be retained across
failed deliveries, set this parameter to 1.
-
Set the maximum number of concurrent endpoints for this activation
specification.
The maximum concurrent endpoints parameter controls
the amount of concurrent work that can be processed by a message bean. The
parameter is used with message-driven beans.
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. However, if message ordering must
be retained across failed deliveries, set this parameter to 1.
-
Save your changes to the master configuration.
For additional information about tuning the throttling of message-driven
beans, including controlling the maximum number of instances of each message
bean and the message batch size for serial delivery, see Configuring MDB throttling for the default messaging provider.
-
Ensure that application servers hosting
one or more messaging engines are provided with an appropriate amount of memory
for the message throughput you require.
You can tune the initial
and maximum Java Virtual Machine (JVM) heap sizes when adding a
server to a messaging bus, that is when you create a messaging engine. You
have the option to do this in any of the following cases:
- When adding a single server to a bus
- When adding a cluster to a bus
- When adding a new server to an existing cluster that is itself a bus member
For an application server that is a bus member of at least one
bus, or a member of a cluster that is a bus member of at least one bus, the
recommended initial and maximum heap sizes are 768MB.
When you are
adding a cluster to a bus, you are recommended to increase the initial and
maximum JVM heap sizes for every server in the cluster to 768MB.
- Increasing the initial heap size improves the performance for small average
message sizes
- Increasing the maximum heap size improves the performance for higher average
message sizes
-
Reduce the occurrence of OutOfMemoryError exceptions
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 for reducing the occurrence
of OutOfMemoryError exceptions when processing a large set of messages within
a transaction.
- Increase the JVM heap sizes for the application server.
- Reduce the cumulative size of the set of messages being processed
within the transaction.
-
Change 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.
-
Click
.
-
Enter the required value in the Maximum connections field.
-
Click Apply.
-
Save your changes to the master configuration.
-
Tune 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
-
Assured persistent
For MDB point-to-point messaging, best effort nonpersistent
throughput is more than six times greater than assured persistent. For more
information about reliability levels, see
Message reliability levels - JMS delivery mode and service integration quality of service.