Rule assembly and execution performance
The rule assembly process creates a cache of rules used to execute applications. The caching of rules is essential for the Pega Platform™ to perform efficiently. However, in some situations, rule assembly can be time-consuming and can decrease performance. Pega Platform provides tools to detect rule assembly issues so that you can take appropriate actions to correct or mitigate adverse performance issues.
Performance impacts of rule assembly and execution
Users may notice overall 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 anecdotal evidence, performance analysis tools and system alerts are available to identify performance issues. Rule assembly or rule caching issues may be the cause of general performance issues.
Rule assembly
When a new application is deployed in an environment, users working in the system may initially experience poor application performance. When the application starts, the core Pega Platform orchestrates rules and the application code to retrieve and cache rules. This action is known as rule assembly. Rule assembly is a system process for generating and compiling the Java code that corresponds to the application rules. Pega Platform performs rule assembly when new JVM nodes are started, new code is deployed, or updated rules are executed for the first time in the application. This action is often referred to as First Use Assembly (FUA). Once users have executed the vast majority of rules, the system performance is optimized as the code is maintained in cache.
A large number of new or updated rules can significantly impact performance. When existing rules are updated, the cached versions are marked 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. These results may cause a misinterpretation of actual application performance.
Rule caching
As an application is extended, the application can add large numbers of rulesets and access groups. Excessive rule caching due to numerous access groups and combinations of rulesets may impede performance.
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.
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 may log in to the system to process inbound calls for claims, and a customer may log in to the application’s self-service website. Each user has a unique access group and ruleset list. Pega Platform manages each access group as a separate cache instance, which utilizes system memory and CPU.
Check your knowledge with the following interaction.
Diagnosis and addressal of rule assembly and caching issues
Excessive rule caching and unneeded rulesets slow system performance. Many rule assembly and caching issues are preventable with careful design-time planning. Minimizing variations in ruleset lists and limiting the users who can check out rules reduces potential performance problems.
When an operator has Allow rule check out enabled, a personal ruleset is created where the checked out rules reside. This feature creates a unique ruleset list that generates a separate cache. It is a best practice to ensure only system administrator operators have this option enabled in non-development environments.
Note: The Allow rule check out option is available on the Security tab of the operator ID record.
To diagnose rule assembly and caching issues, read the Rule Assembly (RA) statistics. To view the RA statistics for an individual, run the My Performance Details tool and enter the user ID in the User ID is Equal field. To view the RA statistics for an application, run the Performance Analyzer (PAL) tool.
Note: The My Performance Details tool is available in Dev Studio by navigating to Configure > System > Performance > My Performance Details. The PAL tool is available in Dev Studio by navigating to Configure > System > Performance > PAL. 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 are high, then an issue exists in rule assembly or caching.
Consider the Rule I/O Elapsed and RA Elapsed readings. Rule I/O Elapsed indicates the time spent retrieving resolved rules from the database, while RA Elapsed indicates the time spent on rule assembly and caching. High rule I/O or rule assembly readings signal that the system is assembling rules unnecessarily.
Note: For more information on PAL tools, see the Pega Community articles Overview of the Performance Tools (PAL) and Interpreting the Performance Tool (PAL) Detail display.
Check your knowledge with the following interaction.
Causes of excessive rule assembly
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, they perform their own rule assembly, which slows down performance. At design-time, take care to ensure that operators utilize common access groups. The access groups must use the same application rule when possible. Users who perform the same functions in the application must all have the same access group specified in their operator ID records.
Caution: 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 therefore rule caches.
Rule assembly also occurs when a ruleset or application is migrated or imported to a new system. 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.
Note: For additional information on running Static Assembler, see the Pega Community articles Preassembling rules in an application and How to reduce rules assembly processing in a production system.
Alerts are generated for rule assembly issues. The following alerts are produced if rule assembly is not performant. A review of the alert log may assist in identifying assembly issues.
PEGA0032- Rule change (update, deletion, or creation) produces many invalid entries in the rule assembly cache.PEGA0037- Rule assembly time exceeds a threshold.PEGA0038- The wait time for rule assembly cache access exceeds a threshold.
Excessive rule assembly management
You can manage excessive rule assembly by minimizing the number of ruleset lists in use. As a starting point, open the Active Rule Set List report to monitor sudden increases in the number of ruleset lists. For example, look for branch rulesets that must not be in a production system.
Note: The Active Rule Set List report is available in Dev Studio by clicking Configure > System > Performance > Active Rule Set List.
The following actions can help you minimize the number of ruleset lists in use:
- Merge ruleset branches before migrating an application. Use branches to isolate rules under development from the production environment. Avoiding the use of branches in production prevents branch rulesets from impacting rules assembly.
- 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 in an application into the same access group.
- Disable rule checkout for users who do not update rules. Enabling rule checkout creates a personal ruleset for a user. This configuration provides that user with a unique ruleset list. If a user does not update rules, disable the rule checkout option on the user's operator ID record to avoid an unneeded ruleset variance.
- 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 in a consistent order. This approach may include refactoring an application to create a built-on application.
Check your knowledge with the following interaction.
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?