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 steps below. You can also
set these parameters by using the wsadmin tool.
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 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.
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.
- 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.