13 Tuning WebLogic JMS Store-and-Forward

Oracle WebLogic Server JMS provides advanced Store-and-Forwarding (SAF) capability for high-performance message forwarding from a local server instance to a remote JMS destination. Get the best performance from SAF applications by following the recommended practices and tips.

• Best Practices for JMS SAF

• Tuning Tips for JMS SAF

See Understanding the Store-and-Forward Service in Administering the Store-and-Forward Service for Oracle WebLogic Server.

• Best Practices for JMS SAF
  Learn the best practices for JMS SAF.
• Tuning Tips for JMS SAF
  For better performance of JMS SAF, use the recommended tuning tips.

Best Practices for JMS SAF

Learn the best practices for JMS SAF.

• Avoid using SAF if remote destinations are already highly available. JMS clients can send directly to remote destinations. Use SAF 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.

• Configure separate SAF Agents for JMS SAF and Web Services Reliable Messaging Agents (WS-RM) to simplify administration and tuning.

• Sharing the same WebLogic Store between subsystems provides increased performance for subsystems requiring persistence. For example, transactions that include SAF and JMS operations, transactions that include multiple SAF destinations, and transactions that include SAF and EJBs. See Tuning the WebLogic Persistent Store.

• Tune message load balancing to match your preference. See SAF Load Balancing in Administering the Store-and-Forward Service.

Tuning Tips for JMS SAF

For better performance of JMS SAF, use the recommended tuning tips.

• Target imported destinations to multiple SAF agents to load balance message sends among available SAF agents.

• Consider using a separate remote SAF context for each SAF destination for better performance. SAF destinations that use the same remote SAF context are typically single threaded.

• Increase the JMS SAF Window Size for applications that handle small messages. By default, a JMS SAF agent forwards messages in batches that contain up to 10 messages. For small messages size, it is possible to double or triple performance by increasing the number of messages in each batch to be forwarded. A more appropriate initial value for Window Size for small messages is 100. You can then optimize this value for your environment.

  Changing the Window Size for applications handling large message sizes is not likely to increase performance and is not recommended. Window Size also tunes WS-RM SAF behavior, so it may not be appropriate to tune this parameter for SAF Agents of type Both.

  Note:

  For a distributed queue, WindowSize is ignored and the batch size is set internally at 1 message.

• Increase the JMS SAF Window Interval. By default, a JMS SAF agent has a Window Interval value of 0 which forwards messages as soon as they arrive. This can lower performance as it can make the effective Window size much smaller than the configured value. A more appropriate initial value for Window Interval value is 500 milliseconds. You can then optimize this value for your environment. In this context, small messages are less than a few K, while large messages are on the order of tens of K.

  Changing the Window Interval improves performance only in cases where the forwarder is already able to forward messages as fast as they arrive. In this case, instead of immediately forwarding newly arrived messages, the forwarder pauses to accumulate more messages and forward them as a batch. The resulting larger batch size improves forwarding throughput and reduces overall system disk and CPU usage at the expense of increasing latency.

  Note:

  For a distributed queue, Window Interval is ignored.

• Set the Non-Persistent QOS value to At-Least-Once for imported destinations if your application can tolerate duplicate messages.