Rule assembly and execution performance
The rule assembly process creates a cache of rules that are used to run applications. The caching of rules is essential for Pega Platform™ to perform efficiently. However, rule assembly issues can decrease performance. Pega Platform provides tools to detect rule assembly issues so that you can take appropriate actions to correct or mitigate slow performance.
Performance impacts of rule assembly and execution
In some situations, users might notice slow response times when working in an application, not just while performing specific tasks such as creating reports or updating calculated values in a form. In addition to user feedback, performance analysis tools and system alerts are available to identify performance problems. Rule assembly or rule caching issues may be the cause of general performance issues.
Rule assembly
When the application starts, Pega Platform runs the application code to retrieve and cache rules. This action is known as rule assembly. Rule assembly is a system process to generate and compile the Java code that corresponds to the application rules.
First use assembly (FUA)
When a new application is deployed in an environment, many new or updated rules can significantly impact performance. Users that work in the system may experience poor application performance initially.
To optimize the application performance, Pega Platform performs FUA when:
- New Java Virtual Machine (JVM) nodes are started.
- New code is deployed.
- Updated rules run for the first time in the application.
Once users have run most rules, the system performance is optimized as the code is stored in the cache.
Rule caching
A rule cache is an in-memory collection of recently used rules. Pega Platform maintains rule caches to improve application performance by avoiding unnecessary rule resolution and database interactions. When an application requests a rule, Pega Platform runs the rule if it is in the cache. If the rule is not in the cache, Pega Platform adds the rule to the cache.
Ruleset list caching
Each unique combination of rulesets, called a ruleset list, has its own cache. If an application has numerous rulesets, Pega Platform uses system resources to cache the ruleset lists. A Pega Platform implementation has a single rulebase that contains rules for various users and can contain rules for multiple applications.
For example, a customer representative might log in to the system to process inbound calls for claims, and a customer might log in to the self-service website of the application. Pega Platform manages each access group as a separate cache instance, which uses system memory and CPU.
In the following image, click the + icons to see where you can evaluate the list of access groups and rulesets in the Operator Profile:
As an application is extended, each built-on application adds rulesets and access groups. Excessive rule caching due to numerous access groups and combinations of rulesets may slow performance.
Check your knowledge with the following interaction:
Diagnosis of rule assembly and caching issues
Many rule assembly and caching issues are preventable with careful design-time planning. Minimizing the variations in ruleset lists reduces potential performance problems. Pega Platform provides tools to assist in finding rule assembly and caching issues.
Rule Assembly statistics
To diagnose rule assembly and caching issues, you view the Rule Assembly (RA) statistics for a user or an application.
- To view RA statistics for a user, run the My Performance Details tool and enter the user ID.
- To view RA statistics for an application, run the Performance Analyzer (PAL) tool.
The statistics presented by the My Performance Details and PAL tools are the same. The difference is that you can look at statistics for individual users with the My Performance Details tool. If the RA statistics, such as RA Elapsed or Rule I/O Elapsed, are high, then an issue exists in rule assembly or caching.
Note: To learn more about PAL, see Interpreting the summary chart in Performance Analyzer.
In the following image, click the + icons to learn more about rule assembly statistics:
Note: When an existing rule is updated, the system marks the cached version for deletion, and the rule is re-cached. For example, after migrating a new application to a QA system, rule assembly time can inflate performance statistics, resulting in a misinterpretation of actual application performance.
Issues
View the time it takes for rule assembly from the Issues icon in the lower right-hand corner of either App Studio or Dev Studio.
Alerts
Pega Platform generates alerts for rule assembly issues. Review the alert log to identify assembly issues, such as:
PEGA0032:The rule change (update, deletion, or creation) produces invalid entries in the rule assembly cache.PEGA0037:The rule assembly time exceeds a threshold.PEGA0038:The wait time for rule assembly cache access exceeds a threshold.
Active Rule Set List
To see the number of active ruleset lists in use, in Dev Studio, open the Active Rule Set List report to monitor increases in the number of ruleset lists. For example, look for branch rulesets that must not be in a production system.
Check your knowledge with the following interaction:
Excessive rule assembly prevention best practices
A common cause of excessive rule assembly is users with different ruleset lists. Differing ruleset lists occur when the access groups each have specific ruleset lists and when individuals can check out rules. If each user has a different access group with slightly different ruleset lists, the system performs additional rule assembly, which slows down performance.
Minimize the excessive rule assembly with the following best practices:
Group application rulesets
Rule assembly occurs when a ruleset or application is migrated or imported to a new system. Manage excessive rule assembly by minimizing the number of ruleset lists in use. Avoid adding a ruleset to multiple application records. Whenever possible, group rulesets into applications to ensure that blocks of rulesets are added to the stack consistently. This approach may include refactoring an application to create a built-on application.
Establish common access groups
Minimize the number of access groups, and use access groups to manage permissions rather than ruleset access. Multiple access groups may refer to the same rulesets but in varying order. To avoid unneeded variations in ruleset lists, group the users who perform the same tasks within an application into the same access group. And the access groups must use the same application rule when possible.
Note: Exercise caution when adding production rulesets to an access group. Production rulesets may be added to the ruleset list in an inconsistent order, increasing the number of unique ruleset lists and rule caches.
Limit rule check out
When an Operator ID has Allow rule check out enabled, the system creates a personal ruleset to store the checked-out rules. The personal ruleset list generates a separate cache. In non-development environments, reduce caching issues by limiting the number of users who can check out rules. Turn off rule checkout for users who do not update rules by disabling the rule checkout option on the Security tab of the user's operator ID record.
Note: It is best practice to limit rule checkout to system administrators in a production environment. For more information, see Standard rule checkout.
Merge branches
Merge ruleset branches before migrating an application. Avoid the use of branches in production to prevent branch rulesets from impacting rules assembly.
The Static Assembler
To reduce the impact of rule assembly after a migration, Pega Platform provides the Static Assembler. This tool enables you to assemble all the rules in an application before a user requests them.
Check your knowledge with the following interaction:
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?