Event Inspector Event Types

27 Performance Tuning 27-1 27 Performance Tuning This chapter describes techniques for increasing Oracle CEP server and application performance, including: ■ Section 27.1, EPN Performance Tuning ■ Section 27.2, High Availability Performance Tuning

27.1 EPN Performance Tuning

When creating your EPN, consider the following performance tuning options: ■ Section 27.1.1, Event Partitioner Channel ■ Section 27.1.2, Batching Channel ■ Section 27.1.3, Scalability Using the ActiveActiveGroupBean For more information, see Chapter 22, Understanding Scalability .

27.1.1 Event Partitioner Channel

You can improve scalability by configuring an event partitioner channel. An event partitioner provides a mechanismWhen 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. For more information, see Section 22.2.1, EventPartitioner .

27.1.2 Batching Channel

By default, a channel processes events as they arrive. Alternatively, you can configure a channel to batch events together that have the same timestamp by setting the wlevs:channel attribute batching to true. For more information, see Section 9.1.6, Batch Processing Channels .

27.1.3 Scalability Using the ActiveActiveGroupBean

Using the com.oracle.cep.cluster.hagroups.ActiveActiveGroupBean, you can partition an incoming JMS stream in Oracle CEP applications by utilizing the notification groups that the ActiveActiveGroupBean creates. For more information, see Section 22.2.2, ActiveActiveGroupBean . 27-2 Oracle Complex Event Processing Developers Guide

27.2 High Availability Performance Tuning

When creating high-availability applications for deployment to multi-server domains, consider the following performance tuning options: ■ Section 27.2.1, Host Configuration ■ Section 27.2.2, High Availability Input Adapter and Quality of Service ■ Section 27.2.3, High Availability Input Adapter Configuration ■ Section 27.2.4, Broadcast Output Adapter Configuration ■ Section 27.2.5, Oracle Coherence Performance Tuning Options For more information, see Section 20.3, Designing an Oracle CEP Application for High Availability

27.2.1 Host Configuration

If you only want availability and are not concerned with recovery time, then it is possible to use smaller, less equipped hosts as secondaries. However, to maximize high availability performance, ensure that all hosts in the multi-server domain are identical: same number and type of processor, same quantity of memory, same number and size of disks.

27.2.2 High Availability Input Adapter and Quality of Service

The Oracle CEP 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 Section 20.2.1, Simple Failover and Section 20.2.2, 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.

27.2.3 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 may increase the likelihood of missed and duplicate events if the primary fails before broadcasting an event message with a large number of events. For more information, see Table 21–3, Child Elements of ha-inbound-adapter for the High Availability Input Adapter .

27.2.4 Broadcast Output Adapter Configuration

Consider decreasing 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.