The document outlines performance optimization techniques for the TrueComp® suite, emphasizing the importance of rule implementation, data quality, and architectural choices. Key strategies include efficient rule evaluation, careful management of reference data, and database tuning to enhance performance. It also discusses the impact of transaction loaders, classifier trees, and the necessity for regular database maintenance to prevent issues like fragmentation.

1. Optimizing TrueComp ® Suite Tips and Tricks David Ritson October 2008

2. Introduction Factors Involving Performance Validate and Transfer Performance Rule Performance Classify Performance Reset Performance Balance and Payment Performance Database Tuning Questions

3. Factors Involving Performance Order of Investigation Increased Impact TrueComp ® Rules SQL Statements Java Distributed Processing and Network Database Schema Database Configuration File System and Operating System

4. Factors Involving Performance The way the rules are implemented is the biggest contributor to performance. This includes: Number of Objects created, Credits, Measurements and Incentives Number of times the rules are evaluated Complexity of Rules Complexity and amount of Rollup and Rolldown

5. Validate and Transfer Performance Consider the CommitSize parameter The cleaner your inbound data is the better. TrueComp ® validation is expensive. Solution Architecture has developed high performance Transaction loaders Transaction loaders which can run in parallel to the pipeline Parameter driven Transaction loader, where parts of the code can be turned off and on We can tailor a loader to meet your needs

6. Rule Performance Rule evaluation versus firing Only create Credits and Measurements which you absolutely need for compensation purposes When building rules remember that territory filters are evaluated before conditions. ‘ ECA’ is the fastest way to allocate credits from transactions Always structure filters to hit the false condition as early as possible

7. Carefully evaluate your options for rolling data up and down the position. Consider using positionRelations to avoid levels of the tree If you roll credit from A to B to C to D then a credit will be created for each position Consider having a positionRelation from A to D This also applies to the rolling of Measurements and Incentives in Reward Use the Transaction Assignments to directly assign credits What is Island processing and why can it make Reward un-scalable? Rule Performance

8. Classify Performance Why does the design of my reference data effect this stage Most issues are seen in the example of ‘skewed’ classifier trees. For example the solution may have 20 classifier trees but 1 tree accounts for 95% of the classifiers Oracle, especially has problems getting the explain plans correct in these cases What new features in 5.2 can help 5.2 supports externalized Classification SQL. The SQL is written to a table from where it can be modified. Modification may include reordering the FROM list, adding hints This makes all classification tunable What can be done if we are not on 5.2 (Oracle) A single database hint can be set which is applied to ALL of the classification inserts Suggest that all classifier data is stored in the GenericClassifier table

9. Reset Performance Reset performance is effected by the following factors Quantity of Results Credits Measurements Incentives Trace records If Keep Posted Results is used What is deferred reset Credits and Trace records are marked as logically deleted This has implications on database size. Regular cleanup pipelines should be executed

10. Balance and Payment Performance Performance issues have been seen at customers which high volumes of generated balances Balances are often generated for small amounts The major impact is on the PaymentSummary stage which gets executed from Reset and Post Solution Architecture have implemented procedures to cap or shut off small balances.

11. Database Tuning SQL tuning Majority of slow queries are fixed by Adding Indexes Changing the query There are queries which may get executed which are not needed by your implementation Solution Architecture can help with any of these scenarios Database tuning The database parameters need to be adjusted to your solutions data volume A common example is parallel query settings What can a DBA do to help? Monitor the storage. One of the big issues we see is fragmentation at the table and index levels. This can be caught fairly easily and the object can be rebuilt to use optimal storage.

12. Other new 5.2 features Data segmentation is available. This is really Oracle partitioning at the table and index level Segmentation provides performance and data management Allows for parallel pipeline runs Solution Architecture has provided custom partitioning for pre 5.2 implementations Some archiving proprosals are being built around partitioning

13. Questions