This is one of the recommendations for performing analysis on business rule to improve performance. The full list is defined in the Business Rule Analysis topic here.
The following list includes business rule elements known to degrade system performance. This list can be used to troubleshoot existing long-running business rules, and can also be reviewed prior to writing new business rules to prevent performance problems.
Avoid Large Transactions
Business actions involve a transaction which allows you to manipulate data in STEP. Business actions with long-running transactions degrade the performance. Additionally, since STEP runs with optimistic locking policy, large transactions increase the probability of optimistic locking failures when running the business action simultaneously. For more information, refer to the Optimistic and Pessimistic Locking Recommendations topic here.
Keeping business rule transactions small means it is necessary to develop business rules while considering the worst-case scenario. This includes the following recommendations:
- Avoid traversing a substantial percentage of the complete data range.
- Keep changes to data local (to the nodes nearest your main data object).
- Avoid business rules that follow and potentially change the objects of transitive closures of referential structures, such as everything underneath a high-level folder in the product hierarchy containing thousands of children. Instead, use a bulk update or a customer specific background process.
If it seems that the business rule transactions cannot follow these recommendations, refer to the 'Reference Target Lock Policy' Parameter section of the Optimistic and Pessimistic Locking Recommendations topic here.
Avoid Large Libraries
On each execution, JavaScript libraries are compiled. Each dependency is stacked into a script which is also compiled using the ScriptEngine.eval() method before each execution of the business rule.
For example, Script S depends on Library A and Library B. Library A depends on B. In this case, the script is stacked as follows:
- A::script
- A::B::script
- B::script
- S::bindings
- S::script
If a business rule depends on a library, the library is compiled as well. By extension, if a business rule uses only a single function within a library, the whole library is still compiled.
And if a library depends on another library, the other library needs to be compiled as well.
STEP caches the scripts instead of reloading them from the database. By default, 100 business rules are cached. Generally, it takes about 500 milliseconds to compile about 8,500 lines of code at each business rule execution.
Important: Be aware that libraries are compiled every time the business rule is executed, which is especially burdensome to performance when libraries depend on each other, and are used in many business rules. Dividing a large library into multiple libraries, but keeping the dependencies, does not resolve the issue.
To improve performance, consider making the library functions local to the business rule.
Avoid Many Inclusions of a Library
Avoid smaller libraries with functions used multiple times by the business rule. For example, a business rule that is applied to 10,000 objects can take up to five times as long to complete compared to running the same function locally in the business rule, instead of from a library.
Evaluate poor performing business rules to determine if one of these scenarios applies:
- If one or more function(s) are called from a large library (thousands of lines), make the library functions local to the business rule itself or use a business function and analyze the level of performance improvement.
- If one or more function(s) are called from a small library but the function is used many times (thousands of executions), make the library functions local to the business rule itself or move the business rule itself to the library or use a business function and analyze the performance improvement.
Avoid Infinite Loops
Infinite loops lead to severe degradation of system performance on the affected application server(s). Ultimately, an infinite loop can make the entire STEP installation unresponsive.
Analyze business rules to determine if infinite loops exist.
Avoid the 'getChildren' Function with Many Nodes
Business rules that use 'getChildren' on a large number of children (more than 10,000) can cause memory problems because the function reads all the children. Instead, use 'queryChildren' function, which limits the number of children affected.
Analyze business rules to determine if 'getChildren' is used on a selection with more than 10,000 children, and update the 'queryChildren' function as needed.
Avoid Updating Data via Business Conditions
Business conditions are optimized for determining the true / false result of read-only scenarios. For details, refer to the Business Conditions topic in the Business Rules documentation here.