Tune messaging performance with service integration

To help optimize performance, we can set tuning properties that control the performance of messaging applications deployed to use service integration technologies.

To optimize the performance of messaging with service integration technologies, we can use the administrative console to set various parameters as described in the following steps. We can also set these parameters by .

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 Tune the application serving environment.

• View the Available Message Count on a destination.

  View the Available Message Count on a destination enables you to determine whether the message consumers are able to cope with the 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.

  1. Enable AvailableMessageCount statistics for a queue. If we restart the administrative server, enable AvailableMessageCount statistics again because such runtime settings are not preserved when the server is restarted.

     1. In the navigation pane, click Monitoring and Tuning -> Performance Monitoring Infrastructure (PMI).

     2. In the content pane, click server_name.

     3. Click the Runtime tab.

     4. In the Currently monitored statistic set, click Custom.

     5. On the Custom monitoring level panel, click SIB Service > SIB Messaging Engines > engine_name > Destinations > Queues > queue_name.

     6. Select the AvailableMessageCount option.

     7. Click Enable.

  2. View the available message count for a queue.

     1. In the navigation pane, click Monitoring and Tuning -> Performance Viewer -> Current activity.

     2. In the content pane, click server_name.

     3. Click Performance Modules > SIB Service > SIB Messaging Engines > engine_name > Destinations > Queues > queue_name.

     4. Click View Module(s) at the top of the Resource Selection panel. This displays the AvailableMessageCount data in the Data Monitoring panel, located on the right side.

        We can use the Data Monitoring panel to manage the collection of monitoring data; for example, we 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.

  We can tune the initial and maximum Java Virtual Machine (JVM) heap sizes when adding a server to a messaging bus, that is when creating 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 WAS 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.

Related tasks

Add a server as a new bus member

Add a cluster to a bus for high availability or scalability

Add a cluster to a bus with a custom configuration

Add a cluster to a bus without using messaging engine policy assistance

Java virtual machine settings

Tune messaging performance for the default messaging provider