Tuning your event runtime configuration

Some tuning of the system might lead to higher performance when processing events.

About this task

When considering how you tune your system, there are two main areas to look at:

The event runtime and WebSphere® Application Server
JMS messaging

Tuning with the event runtime and WebSphere Application Server

About this task

There are several tasks that you can do to tune your system by configuring the event runtime andWebSphere Application Server. You can select from the following tasks that might improve performance:

Procedure

Turn off logging. For more information, see Logs.
Turn off the recording of history, if not required. See Configuring the event runtime to record history.
Use connectors only if required.
If events are already in Decision Server Events format, better performance might be achieved by avoiding the use of connectors. Send events directly to the event destinations and receive actions directly from the action destinations. For example, consider using the destinations jms/eventDestination, jms/durableEventDestination, jms/actionTopic and jms/durableActionTopic.
Ensure that there are sufficient event rule processing threads. If you are unable to achieve full processor utilization on the Decision Server Events server, consider increasing the value of the property as.director.server.ruleProcessorInstances.
Tune the Decision Server Events database:
- Ensure that the database is tuned (or auto tuned) for the workload. The sizes of Log File and Buffer Pool are important. See the documentation for your database manager.
- Consider using a remote database with fast disk subsystems for data and logs. Ideally place data and logs on separate devices.
Tune the JVM:
- The default heap settings (minimum 512MB, maximum 1024MB) are acceptable for many applications. The optimal tuning depends on the available free memory and the nature of the workload, but the following configurations are suitable for a wide range of Operational Decision Manager workloads. You can set these parameters by using the WebSphere Application Server administrative console (Application Servers > server1 > Java and Process Management > Process Definition > Java Virtual Machine):
  - In this configuration, a 32-bit JVM with 2 GB of free memory, the first and second parameters set the minimum and maximum heap size. The third parameter sets a generational garbage collection policy with a 1024 MB nursery heap, meaning that 1024 MB of the heap is used for short lived objects and the remainder of the heap is used for longer lived objects:
    Initial heap size: 1280 (MB).
    
    Maximum heap size: 1280 (MB).
    
    Generic JVM arguments: -Xgcpolicy:gencon -Xmn1024M
  - In this configuration, a 64-bit JVM with 8 GB of free memory, you set a 4096 MB heap with a 2048 MB nursery:
    Initial heap size: 4096 (MB).
    
    Maximum heap size: 4096 (MB).
    
    Generic JVM arguments: -Xgcpolicy:gencon -Xmn2048M
- For more information, see Tuning the JVM.
Increase the concurrency:
If you are using the File System, HTTP, JDBC, JMS, or SOAP action connectors and you see messages for actionTopic or durableActionTopic, increasing the concurrency might improve the rate at which actions are processed.
1. In the navigation tree of the WebSphere Application Server administrative console, click Resources > JMS > Activation specifications, then select the activation specification that you want to modify. Activation specifications for the action connectors are:
  - File System: wbeca_file_as
  - HTTP: wbeca_http_as
  - JDBC: wbeca_jdbc_as
  - JMS: wbeca_jms_as
  - SOAP: wbeca_soap_as
2. Modify the activation specification according to the messaging provider that you are using:
  - If you are using WebSphere Application Server default messaging, modify the Maximum concurrent MDB invocations per endpoint.
  - If you are using WebSphere MQ as the messaging provider, modify the value of Maximum server sessions on the Advanced properties window.

Tuning with JMS messaging

About this task

There are several tasks that you can do to tune your system that are specific to JMS messaging. You can select from the following tasks that might improve performance:

Procedure

For persistent messaging, consider using fast disk subsystems for data and logs. Ideally place data and logs on separate devices.
If you are using WebSphere MQ as the JMS provider:
- The key tuning parameters relate to queue manager logs, channels, and listeners and queue buffer size. See Configuring and tuning WebSphere MQ for performance on Windows and UNIX.
- Consider delivering the messages in batches from the input topic to Decision Server Events. This method is useful for non-persistent, non-durable WebSphere MQ JMS events. The batch size is configured by using the WebSphere Application Server administrative console (Servers > Application servers > server1 > Messaging > Message Listener Service > Listener Ports > wbe_events > Maximum Messages). However, if one of the messages in the batch fails, the whole batch is put back on the queue for processing.
If you are using WebSphere Application Server default messaging as the JMS provider:
- The key tuning parameters relate to the choice of message reliability level, activation specifications, and size of the discardable data buffer. See Tuning messaging performance with service integration technologies.
- Activation specification: Particularly for non-durable JMS events, consider delivering the messages in batches from the input topic to Decision Server Events. This method can deliver events more efficiently. Use the WebSphere Application Server administrative console (for example, Resources > JMS > Activation specifications > wbe_events, and set Maximum batch size).