This chapter provides information on various methods to improve message bridge performance.
This chapter includes the following sections:
Avoid using a Messaging Bridge if remote destinations are already highly available. JMS clients can send directly to remote destinations. Use messaging bridge in situations where remote destinations are not highly available, such as an unreliable network or different maintenance schedules.
Use the better performing JMS SAF feature instead of using a Messaging Bridge when forwarding messages to remote destinations. In general, a JMS SAF agent is significantly faster than a Messaging Bridge. One exception is a configuration when sending messages in a non-persistent exactly-once mode.
Note:
A Messaging Bridge is still required to store-and-forward messages to foreign destinations and destinations from releases prior to WebLogic 9.0.When the Asynchronous Mode Enabled attribute is set to false and the quality of service is Exactly-once, the Batch Size attribute can be used to reduce the number of transaction commits by increasing the number of messages per transaction (batch). The best batch size for a bridge instance depends on the combination of JMS providers used, the hardware, operating system, and other factors in the application environment. See "Configure transaction properties" in Oracle WebLogic Server Administration Console Online Help.
When the Asynchronous Mode Enabled attribute is set to false and the quality of service is Exactly-once, the BatchInterval attribute is used to adjust the amount of time the bridge waits for each batch to fill before forwarding batched messages. The best batch interval for a bridge instance depends on the combination of JMS providers used, the hardware, operating system, and other factors in the application environment. For example, if the queue is not very busy, the bridge may frequently stop forwarding in order to wait batches to fill, indicating the need to reduce the value of the BatchInterval attribute. See "Configure transaction properties" in Oracle WebLogic Server Administration Console Online Help.
An Exactly-once quality of service may perform significantly better or worse than At-most-once and Duplicate-okay.
When the Exactly-once quality of service is used, the bridge must undergo a two-phase commit with both JMS servers in order to ensure the transaction semantics and this operation can be very expensive. However, unlike the other qualities of service, the bridge can batch multiple operations together using Exactly-once service.
You may need to experiment with this parameter to get the best possible performance. For example, if the queue is not very busy or if non-persistent messages are used, Exactly-once batching may be of little benefit. See "Configure messaging bridge instances" in Oracle WebLogic Server Administration Console Online Help.
If message ordering is not required, consider deploying multiple bridges.
Multiple instances of the bridge may be deployed using the same destinations. When this is done, each instance of the bridge runs in parallel and message throughput may improve. If multiple bridge instances are used, messages will not be forwarded in the same order they had in the source destination. See "Create messaging bridge instances" in Oracle WebLogic Server Administration Console Online Help.
Consider the following factors when deciding whether to use multiple bridges:
Some JMS products do not seem to benefit much from using multiple bridges
WebLogic JMS messaging performance typically improves significantly, especially when handling persistent messages.
If the CPU or disk storage is already saturated, increasing the number of bridge instances may decrease throughput.
A general bridge configuration rule is to provide a thread for each bridge instance targeted to a server instance. Use one of the following options to ensure that an adequate number of threads is available for your environment:
Use the common thread pool—A server instance changes its thread pool size automatically to maximize throughput, including compensating for the number of bridge instances configured. See "Understanding How WebLogic Server Uses Thread Pools" in Administering Server Environments for Oracle WebLogic Server.
Configure a work manager for the weblogic.jms.MessagingBridge class. See "Understanding Work Managers" in Administering Server Environments for Oracle WebLogic Server.
Use the WebLogic Server Administration Console to set the Thread Pool Size property in the Messaging Bridge Configuration section on the Configuration: Services page for a server instance. To avoid competing with the default execute thread pool in the server, messaging bridges share a separate thread pool. This thread pool is used only in synchronous mode (Asynchronous Mode Enabled is not set). In asynchronous mode the bridge runs in a thread created by the JMS provider for the source destination. Deprecated in WebLogic Server 9.0.
Ensure that the bridge resource adapter pool is twice as large as the number of bridges. See "Resource Adapters" in Administering the WebLogic Messaging Bridge for Oracle WebLogic Server.
If the bridge is listening on a topic and it is acceptable that messages are lost when the bridge is not forwarding messages, disable the Durability Enabled flag to ensure undeliverable messages do not accumulate in the source server's store. Disabling the flag also makes the messages non-persistent. See "Configure messaging bridge instances" in Oracle WebLogic Server Administration Console Online Help.
If a messaging bridge source or target is a WebLogic destination, deploy the bridge to the same WebLogic server as the destination. Targeting a messaging bridge with one of its destinations eliminates associated network and serialization overhead. Such overhead can be significant in high-throughput applications, particularly if the messages are non-persistent.
The Asynchronous Mode Enabled attribute determines whether the messaging bridge receives messages asynchronously using the JMS MessageListener interface at http://docs.oracle.com/javaee/5/api/javax/jms/MessageListener.html, or whether the bridge receives messages using the synchronous JMS APIs. In most situations, the Asynchronous Enabled attributes value is dependent on the QOS required for the application environment as shown in Table 15-1:
Table 15-1 Asynchronous Mode Enabled Values for QOS Level
| QOS | Asynchronous Mode Enabled Attribute value |
|---|---|
|
false |
|
|
true |
|
|
true |
Footnote 1 If the source destination is a non-WebLogic JMS provider and the QOS is Exactly-once, then the Asynchronous Mode Enabled attribute is disabled and the messages are processed in synchronous mode.
See "Configure messaging bridge instances" in Oracle WebLogic Server Administration Console Online Help.
A quality of service of Exactly-once has a significant effect on bridge performance. The bridge starts a new transaction for each message and performs a two-phase commit across both JMS servers involved in the transaction. Since the two-phase commit is usually the most expensive part of the bridge transaction, as the number of messages being processed increases, the bridge performance tends to decrease.
This section provides information on how to improve system boot time and general performance of systems that deploy many bridge instances.
Modify the capacity of the connection factory associated with each resource adaptor by adjusting the max-capacity attribute in the weblogic-ra.xml descriptor file. The value of the max-capacity attribute should be at least two times the number of bridge instances.
For example, if your environment has up to ten message bridge instances targeted, a max-capacity attribute setting of 20 in the default configuration is adequate. But if you increase the number of bridge instances to 15, increase the max-capacity attribute to 30. See "Setting the Number of Connection Factories" in Administering the WebLogic Messaging Bridge for Oracle WebLogic Server.
Increase the entire server's thread pool size to something somewhat higher than the number of active bridges. This applies for any XA (transactional) bridge with a batch size higher than 1, or any XA bridge that consumes from a source destination hosted by a non-WebLogic JMS provider.
For example, pass the following on the command line if you have 90 message bridges:
-Dweblogic.threadpool.MinPoolSize=100
This ensures there are enough threads available when affected bridges initialize. If there are not enough threads available, there can be a multi-second delay until a new thread is created.
Provide a thread for each bridge instance targeted to a server instance. See "Changing the Thread Pool Size".