Valid for: Oracle
You can improve the speed of Post when it is processing mostly small transactions, such as those most commonly found in OLTP.
There are two features you can use, depending on the supported database:
Together these features are called Post Enhanced Performance, or PEP.
The Transaction Concurrency feature enables you to configure Post to apply transactions in parallel to increase overall throughput. The smaller the transaction, the bigger the performance gain.
To enable the concurrency feature, set the SP_OPO_DEPENDENCY_CHECK parameter to 1.
Note: This feature may reduce or eliminate the need to run multiple Post processes, but you can still benefit from the use of multiple Post processes because they eliminate a single point of failure. If a Post process fails, the other Post processes will continue, resulting in less recovery time, after the problem is resolved. This feature can be used in a multi-Post configuration, so long as the rules for using multiple processes are followed (such as including all tables with referential integrity in the same process stream). See Configure named post queues for more information about using multiple Post processes.
The Commit Reduction feature enables you to configure Post to combine smaller transactions into larger ones. This reduces the number of commits and acknowledgments that must be processed. The smaller the transaction, the bigger the performance gain.
Commit reduction is enabled by default when you enable the concurrency feature, and it cannot be enabled without enabling concurrency. The size of the combined transaction is controlled by the SP_OPO_COMMIT_REDUCE_MSGS parameter.
This parameter sets the minimum number messages (operations) in the transaction. Post skips the commits of small transactions whose boundaries are within the specified range, and instead applies all of the operations in the combined transaction. The default combined transaction size is 100 messages. To disable commit reduction, set this parameter to a value of 1.
The parameter setting is not an absolute threshold. SharePlex will not break up a transaction across different combined transactions. Therefore, Post may need to exceed that threshold in order to include all of the operations and the commit of the last transaction in the group.
With both concurrency and commit reduction enabled, testing has shown that performance can be increased by as much as two or three times over conventional SharePlex posting speeds.