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.
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.
-
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 or SCA 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.
During
the peak activity period, it is essential to ensure that the messaging
engine has adequate heap size to handle the messaging engine failover
processes. This also applies when the messaging engine is failing
over to another instance in a cluster member environment when the
JVM heap is nearly exhausted. In such situations, you must increase
the maximum heap size value by approximately 512 MB for each of the
cluster members that are eligible to host the messaging engine in
a failover situation. For example, for
WebSphere Application Server on z/OS, the adjunct heap
value must be increased by 512 MB for cluster members associated with
the messaging engine if you are running under conditions that nearly
exhaust the JVM heap.
- 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.