Tuning messaging performance with service integration

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

• 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.

  1. 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.

     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) 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.