To help optimize performance, you can set tuning properties
that control the performance of 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 following steps. 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.
Procedure
- 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.
- 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) in the Resource Selection panel. This action
displays the AvailableMessageCount data in the Data Monitoring panel.
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.
- 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 errors
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 errors occur. Consider one
of the following options for reducing the occurrence of OutOfMemoryError errors 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.
- 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.