Qus: How to increase the performance of trigger?
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.
Trigger Processing Mode = Concurrent, assuming order of processing is not important
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.
Trigger Threads = 4 x CPU, except where order of processing is important and Serial processing mode is use
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).
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
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.
Acknowledgement Queue Size = 2 x Trigger Threads
The potential caveat to this setting is the number of documents that might need to be reprocessed in the event of a server cras