Trigger Retries#
If you are not using trigger retries then set the retry count to 0. This will noticeably improve performance, especially as documents get larger and more complex.
Trigger Processing Mode#
Serial processing mode is used to enforce document order on consumption. In a single instance environment, the order of processing is the order in the queue. In a clustered environment, the order of processing is based on publisher order i.e. an instance acquires ownership for documents from one source and then exclusively processes these in a single threaded fashion the order they appear in the queue. Other sources may be processed by other IS instances in the cluster. For most general purposes, the processing mode will be set to concurrent and this gives far better performance.
Rough Guide:#
Trigger Processing Mode = Concurrent, assuming order of processing is not important
Trigger Threads#
The number of threads should generally be no more than a small multiple of the number of CPU cores available to the IS, also considering that all service threads within the Integration Server must share CPU resources. The number of threads may be increased further where the work done in the service has a relatively low CPU content, for example where there is a lot of IO involved, or where the service thread is waiting for external applications or resources. Setting trigger threads too high will start to incur context-switching overheads at the OS level and within the JVM.
Rough Guide:#
Trigger Threads = 4 x CPU, except where order of processing is important and Serial processing mode is use
Other Considerations#
The amount of work each thread must do and, not just for one trigger but for all thread consumers. If the trigger service is very short and lightweight then it can support more threads than more computationally expensive threads. Document size will play a factor but it’s only one reason that threads become computationally expensive. Review all the triggers in the context of the whole system and not just the single trigger.
Trigger Cache Size and Refill Level#
The trigger cache size defines the number of documents that may be held in memory while documents are unacknowledged on the broker. The cache is filled with documents (in batches of up to 160 at a time) from the Broker, so a larger cache size reduces the number of read activities performed on the Broker. The IS goes back to the Broker for more documents when the documents left in the cache falls below the Refill Level. The objective in setting these parameters is to ensure that whenever a trigger thread becomes available for use, there is a document already in the cache. The Cache Size should be as small as it can be whilst still being effective, to minimize the use of memory in the IS (note the size is specified in documents, not based on total size held). If the processing of documents is generally very short, the cache should be larger. As a rough guide, the cache size may be 5 to 10 times the number of trigger threads, and the refill level 30%-40% of that value (or the refill should be twice the number of trigger threads).
Rough Guide:#
Trigger Cache Size = 5 x Trigger Threads Trigger Refill Level = 2 x Trigger Threads Trigger Cache Memory Usage = Trigger Cache Size x Average Document Size
Other Considerations#
For small documents with lightweight services these setting could be too conservative and for large documents it could be too aggressive.
Acknowledgement Queue Size#
The AckQ is used to collect acknowledgements for documents processed by the trigger threads when they complete. If set to a size of one, then the trigger thread waits for the acknowledgement to be received by the Broker before it completes. If the AckQ size is greater than one, then the trigger thread places the acknowledgement in the AckQ and exits immediately. A separate acknowledging thread polls the AckQ periodically to write acknowledgements to the broker. If the AckQ reaches capacity then it is immediately written out to the broker, with any trigger threads waiting to complete while this operation is done. Setting the AckQ size greater than one enables the queue, and reduces the wait time in the trigger threads. If performance is important, then the AckQ should be set to a size of one to two times the number of trigger threads. Acknowledgements only affect guaranteed document types. Volatile documents are acknowledged automatically upon reading them from the Broker into the Trigger Cache.
Rough Guide:#
Acknowledgement Queue Size = 2 x Trigger Threads
Other Considerations#
The potential caveat to this setting is the number of documents that might need to be reprocessed in the event of a server crash.
In-Memory Storage#
Volatile documents are handled entirely in memory and so the quality of storage is propagated into the handling in the IS as well. Loss of memory results in loss of a volatile document whether it is held by the Broker or by the IS. This is also why acknowledgements are returned to the Broker upon reading a volatile document.
For guaranteed messages, in-memory storage about the state of a message can exist in both the Trigger Cache and in the Acknowledgement Queue. If the IS terminates abnormally, then this state is lost. However, for unacknowledged, guaranteed documents, the redelivery flag will always be set on the Broker as soon as the document is accessed by the IS. Therefore after an abrupt IS termination or disconnection, the unacknowledged documents will be presented either to the same IS upon restart, or once the Broker determines that the IS has lost its session, to another IS in the same cluster.
All these documents will have the redelivery flag set and may be managed using the duplicate detection features, described in the Pub/Sub User Guide.
In such a failure scenario, the number of possible unacknowledged messages will be a worst case of Trigger Cache Size plus Acknowledgement Queue Size. The number of documents that had completed processing but were not acknowledged will be a worst case of Trigger Threads plus Acknowledgement Queue Size. The number of documents that were part way through processing but hadn't completed will be a worst case of Trigger Threads. The number of documents that will have the redelivery flag set but had actually undergone no processing at all will be a worst case of Trigger Cache Size.
Other Considerations#
If the trigger is subscribing to multiple document types (has multiple subscription conditions defined), then the trigger threads are shared by all document types. This may give rise to variations in the processing required for each message and the size of each message in the cache. Where this complicates the situation, it is better to use one condition per trigger.
If document joins are being used, refer to the user guide for information about setting join timeouts. A trigger thread is only consumed when the join is completed and the document(s) are passed to the service for processing.
