Whenever an event that requires an update to a statistic occurs, a trigger entry is added to the
ec_event_trigger database table. A Statistics Collector thread periodically processes a batch of
entries from the ec_event_trigger table, using the data for the event associated with each trigger to
update the relevant statistic(s).

In normal operation, the ec_event_trigger database table will therefore shrink and grow in size as
triggers are added and processed, with the size and rate of change of the table determined by the
amount of activity on the system. The size of the table should tend to zero.

System outages can, in some circumstances, result in problems that affect trigger processing
performance. These include:

* orphaned process or case instances. Triggers associated with these instances cannot be processed
  until the instance is recovered. A separate processing thread is used to periodically recover a
  batch of orphaned instances.
 
* a backlog of triggers in the ec_event_trigger table.

Symptoms resulting from these problems can include:

* Continual growth of the ec_event_trigger table. This could happen either because triggers are not
  being processed at all, or because they are being processed too slowly to clear the backlog caused
  by the outage.

* Statistics for new instances are not being updated, even though triggers are being processed.

Two system properties are provided which can be used to improve trigger processing performance if you
encounter these problems. (You can also use these properties to try and improve performance in normal
operating conditions.)

IMPORTANT: The precise optimal values of these properties will depend on load and specific hardware
metrics for your system. For this reason, you should implement these changes and monitor their impact
on performance on a representative test system first. Do not implement them on a production system
until you have verified that the values are what you require for your production environment.

Statistics Collector - Improving ec_event_trigger Processing Performance

All supported operating systems and databases

1. Add the following properties to the <CONFIG_HOME>\bpm\<BPM_APP_NAME>\configuration\sc.properties
   file:

  * recoveryBatchSize - defines how many orphaned instances are recovered in each batch. A value of
    1500 is suggested as a starting point for testing the impact on performance. (A default value of
    100 is used when the property is not specified. This was increased to 5000 in ActiveMatrix BPM
    version 4.3.0.)

  * eventCommitBatch - defines how many triggers (rows) are processed from the ec_event_trigger table
    in each batch. A value of 2500 is suggested as a starting point for testing the impact on
    performance. (A default value of 100 is used when the property is not specified.)

  For example:

    recoveryBatchSize=1500
    eventCommitBatch=2500

  NOTE: 'eventCommitBatch' replaces the 'instanceBatchSize' parameter which was used in pre 4.x
  versions of ActiveMatrix BPM. 'instanceBatchSize' is obsolete on version 4.x. Although it is still
  included in the sc.properties file, it has no effect and can be removed from sc.properties if
  desired.

2. Add the following DEBUG logger appender to the amx.bpm.app application and use it to monitor the
   impact of your property value changes:

     com.tibco.n2.sc.core.asynch.impl.NativeTriggerBatch
     
   The appender produces log outputs like this:
   
     12 Aug 2019 16:48:28,824 [SC.1.BPMNode_001.1] [DEBUG] [amx.bpm.app] com.tibco.n2.sc.core.asynch.
       impl.NativeTriggerBatch - 100 / 100 events processed successfully (100 staging events deleted)!
       native [78], model [22]
     12 Aug 2019 16:48:28,824 [SC.1.BPMNode_001.1] [DEBUG] [amx.bpm.app] com.tibco.n2.sc.core.asynch.
       impl.NativeTriggerBatch - 0 instances marked for retry (0 instances updated)!
     
3. Increase or decrease the property values until the system is behaving to your satisfaction. (Note
   that continually increasing values will not necessarily improve performance each time. Depending on
   your environment, a value that is too high may result in sub-optimal performance just the same as
   one that is too low.) Contact TIBCO Support if you need further assistance.