Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Tips for optimizing decision strategies

Updated on September 10, 2021

Decision strategies that determine the next-best-action in your application can include components with complex configurations of different rule types. These configurations can lead to poor performance. Use the following guidelines to understand the flow of data in your decision strategy so that you can diagnose and eliminate bottlenecks and other performance issues.

Perform test runs

You can test strategies to find performance issues by performing strategy test runs. The statistics such as the processing speed of records or decisions, time spent in each component, throughput, and the number of processed decisions or records, can help you assess the health of a strategy. For example, by viewing the Time spent statistics, you can get insight into how much time is spent on processing data in each strategy component, whether the indicated amount of time is justified, or whether the component uses a complex processing logic that you can optimize, and so on.

To test a strategy, you provide input data to the strategy components and then run a single case or batch set of cases. Data transforms, data sets, and data flows support the generation of the data objects that contain input data for test runs. The data processing power that is provided by data sets and data flows is best suited for validating your design against sample data from one or more data sources.

For more information, see Configuring a single case run or Configuring a batch case run.

Test your strategy on multiple records. In most cases, 100 records are enough to give you a reliable indication of the performance of your strategy.

Strategy test run panel and test results

Strategy test run panel and test results

Apply filters early

Apply filters in a strategy as early as possible to eliminate data from the strategy flow that is not required to issue a decision. This solution reduces the amount of memory that is needed to process a strategy and decreases the processing time.

Applying early filters

Applying filters early in the flow of strategy

Avoid computing inactive paths in data joins

In complex decision strategies that contain multiple layers of substrategies, you can encounter Data Join components that are always triggered, regardless of their validity in the decision path. This type of design can needlessly extend the strategy processing time and is not recommended.

To illustrate this problem, see the following example strategy: An analysis of a strategy in terms of the number of decisions and time spent in each component

An analysis of a strategy in terms of the number of decisions and time spent in each component

In the preceding strategy, the condition that is configured in the Data Join shape states that the data is matched only if the value of the SubjectID property of the input records is the same. However, even if the processing of the Filter shape results in no output records, the substrategy is still processed, which results in the unnecessary addition of 1.56 seconds to the total processing time.

To process the strategy only when required, use the Switch and Group By components. The Group By component counts the customer records that pass through the Filter component. If at least one customer record passes through the Filter component, the strategy is processed; otherwise, the strategy is not processed.

Optimized strategy

Strategy optimized to avoid processing unused paths

For more information, see Strategy rule: Completing the Strategy tab.

Cache time-consuming expressions

You can cache the global parts of an expression that are not required for each decision. For example, the following Set Property component takes 525.76 milliseconds to compute, which is 12 percent of the total strategy processing time. To a strategy designer, this amount of time might indicate that this element requires optimization.

Set property no cache

Set Property component that takes an excessive amount of time to process

This Set Valid Set Property component sets properties as stated by the following expression:

.D_Date_Start <= DateTime.D_Today     &&
.D_Date_End   >= DateTime.D_Today     &&
.D_Time_Start <= DateTime.D_TimeOfDay &&
.D_Time_End   >= DateTime.D_TimeOfDay
Based on the preceding expression, the DateTime.D_Today and DateTime.D_TimeOfDay properties are retrieved from the clipboard page for each decision. This time-consuming process can be optimized by caching the two properties through an additional Set Property component.

Cached Set Property

Reducing the processing time in a strategy through property caching

The new DataCache Set Property component sets temporary D_Today and D_TimeOfDay properties. This component reduces the processing time of the Set Valid component from 12 percent of the total strategy processing time to 1 percent by using the following expression:

.D_Date_Start <= DataCache.D_Today     &&
.D_Date_End   >= DataCache.D_Today     &&
.D_Time_Start <= DataCache.D_TimeOfDay &&
.D_Time_End   >= DataCache.D_TimeOfDay
You cannot apply this approach to all time-consuming strategy components. For example, a component might consume most of the total processing time of the strategy because it handles an increased number of records. You can view the number of records that pass through each strategy component by selecting the Number of processed records statistics in a batch case test run.
  • Previous topic Timeout exceptions during snapshot generation
  • Next topic Tips for troubleshooting Decision Data Store nodes

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us