Tuning JMS/XLA Applications

Considerations in Tuning JMS/XLA Applications

JMS/XLA has some overhead that makes it slower than using the C XLA API.

In the C API, records are returned to the user in a batch. In the JMS model an object is instantiated and each record is presented one at a time in a callback to the MessageListener method onMessage(). High performance applications can use some tuning to overcome some of this overhead.

Configure xlaPrefetch Parameter

The code underlying the JMS layer that reads the transaction log is more efficient if it can fetch as many rows as possible before presenting the object/rows to the user. The amount of prefetching is controlled in the jmsxla.xml configuration file with the xlaPrefetch parameter.

Set the prefetch count to a large value like 100 or 1000.

Reduce Frequency of Update Acknowledgments

In JMS/XLA, acknowledging updates moves the bookmark and results in updates to system tables. You can typically improve application performance by waiting until several updates have been detected before issuing the acknowledgment. You can control the acknowledgment frequency in either of the following modes.

See XLA Update Acknowledgments.

DUPS_OK_ACKNOWLEDGE, where JMS/XLA prefetches records according to the xlaprefetch setting, and an acknowledgment is automatically sent when the last record in the prefetched block is read.
CLIENT_ACKNOWLEDGE, where you manually call the acknowledge() method on the MapMessage instance as desired.

The appropriate choice for acknowledgment frequency depends on your application logic. Acknowledging after every 100 updates, for example, has been used successfully. Be aware, however, that there is a trade-off. Acknowledgments affect XLA log holds, and acknowledging too infrequently may result in undesirable log file accumulation. (Also see XLA Bookmarks and Transaction Log Holds.)

Note:

In DUPS_OK_ACKNOWLEDGE or CLIENT_ACKNOWLEDGE mode, the reader application must have some tolerance for seeing the same set of records more than once.

Handling High Event Rates

The synchronous interface is suitable only for applications with low event rates and for which AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE acknowledgment modes are acceptable.

Applications that require CLIENT_ACKNOWLEDGE acknowledgment mode and applications with high event rates should use the asynchronous interface for receiving updates. They should acknowledge the messages on the callback thread itself if they are using CLIENT_ACKNOWLEDGE as acknowledgment mode. See Receiving and Processing Updates.