We have a v6.5 pub/sub integration that needs to preserve the publishing order of documents; therefore, the subscribing trigger has Processing Mode = Serial. The published documents are relatively small - less than 5K. We do expect 100s of documents to be published in immediate succession.

Could we improve document throughput between the Broker and IS by increasing the Trigger Queue Capactity and Refill level parameters? What are the guidelines/caveats to consider when increasing these parameters? They’re currently set at 10/4. Would it help performance to set them to 100/40 or 1000/400?

Thanks in advance

Here are the guidelines (find it in GEAR 6 Performance Tuning White Paper.pdf):

“Document Triggers
• Internally, when the broker receives a document that is subscribed to by the Integration Server, the document is queued. The integration Server then pulls a number of documents in the queue into a local trigger store in the Integration Server. From there, it asynchronously dispatches the documents to the target services. It is possible to configure the amount of this “prefetching” that the Integration Server does by setting the trigger capacity and refill level in the Developer UI (or by modifying parameters in the dispatch.cnf file). The trigger capacity specifies the maximum number of document in the trigger store. The refill level specifies the minimum threshold of documents in the trigger store that will cause the Integration Server to get additional documents queued in the broker. Increasing these numbers will allow the Integration Server to prefetch more records from the Broker, which should improve performance slightly. However, it is important to size the trigger store appropriately using the Admin UI to ensure that it can accommodate documents the peak number of documents.”

There is a technical note available on Advantage named “Optimizing Publish/Subscribe Solutions” that may be helpful. On the Advantage menu, select Best Practices | Product Technical Notes. It’s the first document listed. Be aware that the “client-side queuing” mentioned in the doc is no longer available.