Event Processor and Event Queue Recommendations

This is one of the data gathering methodologies and recommendations for functional performance improvement. The full list is defined in the Performance Recommendations topic.

Event processors and queues are used for asynchronous processing, such as auto-purging revisions on schedule or performing a delayed approval after import. Warnings and/or critical issues in asynchronous processing can have an influence on the performance of the system.

For general information on event processors and event queues, refer to the Event Processors topic and the Event Queues topic , both in the System Setup documentation.

For more information, refer to the Monitoring topic of the Administration Portal documentation.

Run Without Warnings and Errors

Warnings and errors are visible in the event processor background processes. For optimal processing, no warnings or errors should be reported.

For example, the following image shows the business rule execution report for an event processor. In this illustration, the event processor initiated a business rule with a setting 'Valid Object Types = All object types valid' but the event processor is not valid for all object types. Business rules initiated via an event processor should be defined with specific object type(s) rather than setting all object types as valid.

Optimize STEP Setup for Performance

Use the following setup recommendations within the event processor configuration to optimize performance. For detail on all parameters, refer to the Event Processors topic in the System Setup documentation...

  • The User Running Event Processor Plugin parameter defines the privileges that are checked when the event processor is invoked. For each piece of information processed, all privileges are checked for the selected user. Creating a user with relatively few and broad permissions explicitly for event processors can improve performance dramatically.

  • The Number of Events to Batch parameter defines the number of events processed in a batch. While the events are handled one-by-one, committing large batches are more effective and improve performance. For the event processors:

    • Set the 'Number of events to batch' parameter no larger than the max size defined in the sharedconfig.properties file for the OutboundMessageProcessor.BatchEventsMaxSize property. By default, this is 10,000. Lower this number if you experience system memory problems.

    • Analyze the schedules and the background processes to determine how many events are processed in each batch.

For example, in the following image, the number of events in a batch is 1 or 2, so the number of events to batch could be set to five (5). However, if the schedule is increased, e.g., once per 15 minutes instead of once every minute, then the number of events in a batch could be an average of 30. In that case, the 'Number of events to batch' parameter could be set to 30.

  • The Days to Retain Events parameter is the number of days to keep events once processed. However, the value should be set to 0 since this parameter has no impact on event processors.
  • The Schedule parameter can be set to run every minute, but this will have a negative impact on performance. The 'Start every minute' option should be used only in rare and necessary situations.

Analyze Asynchronous Processing

Analyze the state of asynchronous processing using the 'Sensors for external monitoring' option as follows.

  1. On the Start page, click the System Administration button, and supply the login credentials.
  2. On the Monitoring tab, open the Additional Links section and click the 'Sensors for external monitoring' link to display the list of monitors.
  3. For each sensor with a 'Warning' or 'Critical' status, click the sensor name link to display the details of the status.
  4. Resolve the issue indicated in the sensor log.

For example, the following sensor has a 'Critical' status.

The details show that event queue 'DynamoDBEvents' has too many events queued.

In the workbench, this event queue shows that the event queue is disabled but is still reading events. Since the latest change on this event queue is months ago, and it is on the production environment, the event queue is no longer being used and can be removed.

Legacy - Queues and Queue Size

Legacy background process (BGP) functionality uses multiple specified queues (BGP Legacy Multiple Queues), while the recommended BGP execution mechanism runs BGPs based on the priority of the BGP and the created time. Refer to the BGP One Queue topic in the System Setup documentation.

The event processor initiates a background process to handle the processing.

  • The legacy Queue for event processor parameter stores the queue that is used by the background process to poll the event processor. The default value is EVPROC.

  • The queue for associated processes is used by the background processes to handle the actual processing. The queue is identified on the BG Processes tab: select the Event Processor BGP node to display the Process Overview tab and open the 'Process Type Information' flipper. The default value is EventProcBGP. For details on identifying and editing the queue being used, refer to the Modifying Configuration for Legacy BGP Queues in the System Setup documentation.

STEP legacy functionality allows you to define a separate queue for event processors to ensure only events for this process are read.

The first time you activate the event processor, a queue with the specified name is created if it does not already exist.

A background process (BGP) queue allows prioritizing system processes to ensure high- level system performance. BGP queues are named and configured to control which processes run on which server and how many can run at the same time on each server.

Note: Parallel processing is set by increasing the queue size for the event processor background processes and can improve performance, but can also cause optimistic locking issues when parallel processes attempt to view / update the same node at the same moment. A queue size of 1 means only one process can run at a time, while a queue size of 2 means two processes can run concurrently.

Recommendations

Configure the 'One Queue' BGP execution mechanism to run BGPs based on the priority and the created time. Refer to the BGP One Queue topic in the System Setup documentation.

In the event processor settings, legacy functionality uses separate queues for event processors, especially for those with long-running events, as defined in the BGP Legacy Multiple Queues topic.

Test parallel background processing using an increased the queue size in a test environment before increasing it in production. Increase the queue size to 2 for the event processor background process via the following case-sensitive properties in the sharedconfig.properties file:

  • BackgroundProcess.ProcessType.[process type ID].Queue=[queue]

    For example:

    BackgroundProcess.ProcessType.EventProcBGP.Queue=EventProcBGPQ

  • BackgroundProcess.Queue.[name].Size=[number of allowed concurrent processes]

    For example:

    BackgroundProcess.Queue.EventProcBGPQ.Size=2

  • Restart the application server to apply the changes to the properties file.

Refer to the Background Processes and Queues topic in the System Setup documentation for examples of parallel and multithreading properties.

Consider In-Memory for Event Processors

When the other event processor recommendations have been followed and additional performance improvement is needed, consider In-Memory since it provides faster read operations.

For more information, refer to the In-Memory Database Component for STEP topic in the Resource Materials online help documentation.