16 Performance Tuning

This chapter describes techniques for improving Oracle Stream Analytics application performance by using partitioning and batching, and includes information specific to high availability performance tuning.

This chapter includes the following sections:

16.1 Channel and JMS Performance Tuning

You can tune application performance of by configuring an event partitioner channel, batching events, and partitioning an incoming Java Message Service (JMS) stream.

Event partitioner channel: You can improve scalability by configuring an event partitioner channel. When you configure a channel to use an event partitioner, each time an incoming event arrives, the channel selects a listener and dispatches the event to that listener instead of broadcasting each event to every listener for partitioning events on a channel across its output event sinks.

Batching channel: By default, a channel processes events as they arrive. Alternatively, you can configure a channel to batch events that have the same time stamp and were output from the same query by setting the wlevs:channel attribute batching to true. See Batch Processing Channels for an example.

Scalability with ActiveActiveGroupBean. Use com.oracle.cep.cluster.hagroups.ActiveActiveGroupBean to partition an incoming JMS stream in Oracle Event Processing applications with the notification groups that the ActiveActiveGroupBean creates. For more information, see Scalable Applications.

16.2 High Availability Performance Tuning

When creating high-availability applications for deployment to multiserver domains, consider the following performance tuning options:

Host configuration: To maximize high availability performance, ensure that all hosts in the multiserver domain are configured with equivalent processing capacity (similar number and type of CPUs), and that all hosts have sufficient memory and disk for the needs of the application

High availability input adapter and quality of service: The Oracle Stream Analytics high availability input adapter is applicable to all high availability quality of service options. However, because the high availability input adapter increases performance overhead, it is not appropriate for some high availability quality of service options, such as those described in Simple Failover and Simple Failover with Buffering. If you are using application time from the event, then you do not need to use the input adapter. Application time from the event is always preferable from a performance standpoint.

High availability input adapter configuration: Consider increasing the batch-size to reduce the amount of time the primary server spends broadcasting event messages and to reduce the amount of time the secondary servers spend processing these messages. Increasing the batch-size can increase the likelihood of missed and duplicate events when the primary fails before broadcasting an event message with a large number of events.

Broadcast output adapter configuration: Decrease the trimming-interval to reduce the amount of time the primary server spends broadcasting trimming messages and to reduce the amount of time the secondary servers spend processing these messages. Decreasing the trimming-interval may increase recovery time as the new primary server's in-memory queue will be more out of date relative to the old primary.

Oracle Coherence performance tuning options. When you configure Oracle Coherence in a high-availability architecture, consider the following options:

  • Increase the Oracle Coherence heartbeat time out machine frequency to reduce the number of heartbeats before failure. See Oracle Coherence Developer's Guide at http://download.oracle.com/docs/cd/E15357_01/coh.360/e15723/tune_perftune.htm.

  • Implement the Oracle Coherence Portable Object Format (POF) for serialization to improve messaging performance. POF is a language agnostic binary format that was designed to be very efficient in both space and time. Using POF instead of Java serialization can greatly improve performance.