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.

How to reduce rules assembly processing in a production system

Updated on September 10, 2021


A production system shows these symptoms:

  • Application response time is poor
  • PAL readings show that rules assembly is occurring, even though no new rules are being created, or very few new rules are being created.
  • System Console (PRMonitorServlet), Class Loader Status page shows a large number (greater than 10) of invalidated classes

Understanding Rules Assembly

The first time that a particular rule is referenced (for a specific set of rule-resolution characteristics), Process Commander generates, compiles, loads, and executes the Java source code for a unique Java. This process is referred to as rules assembly (RA) or first use assembly (FUA). Subsequent references to the same rule (under the same rule-resolution characteristics) will re-use the same Java class that has been generated and compiled.

In an production system, users execute a stable collection of rules repeatedly, and rule updates or rule additions are rare. As a result, when a production user (or other requestor) needs to execute a rule, the system will find already assembled Java code a very high percentage of the time. When this does not happen, so that rules assembly continues to occur, the application's overall performance can be severely impacted.

Process Commander maintains a global First Use Assembly (FUA) cache for the system, as well as personal FUA caches for each user that has rule checkout enabled in their operator ID. In V4.2SP4, the maximum number of entries that can be held in each of these caches is 3,000. In V4.2SP6 and later, the pegarules.xml defines a default of 20.000 entries.

When the FUA cache becomes full, i.e. reaches the maximum number of entries, Process Commander will remove the older entries, and in doing so will invalidate the associated Java classes.

If several distinct RuleSet lists are in use and / or users have rule checkout, you effectively get FUA cache duplication. For example, if for one user using the application there are 2000 FUA cache entries for their RuleSet list, then for 8 different users with different rule set lists there will be close to 16000 FUA cache entries. They are the same rules, but they have different FUA cache entries due to the different RuleSet list hash signatures.

In applications in which there are a large number of rules, having many distinct RuleSet lists and / or users with Allow rule check-out? enabled (on the Security tab of the Operator ID form) can result in continuous rules assembly. (This setting provides a personal, private RuleSet to the operator, so even if the operator never checks out any rule, the operator's RuleSet list is distinct from all other operators' RuleSet list, so each rule the operator executes is assembled just for that operator.)

Diagnostic Steps


Use the PAL performance tool to take PAL readings. Monitor the rules assembly readings. These should be low, ideally zero.

System Console (PRMonitorServlet)

Monitor the number of invalidated classes on the Class Loader Status page. This should be low, ideally zero.


Eliminate the distinct RuleSet lists that are not required

Review user RuleSet lists, which are derived from on the their organization setup, access group setup, and operator ID configuration. If there are users that have distinct RuleSet lists for no business reason, or if some users have rule checkout that should not, consolidate and remove those privileges as appropriate.

  1. Minimize the number of distinct access groups that are referenced in Operator ID, organization, and division data instances.
  2. Clear the Allow rule check box on the on the Security tab of the Operator ID form for all but those operators who truly need this capability in a production system.

Increase the FUA Cache Size

You can adjust the FUA cache configuration, including the maximum number of entries in the cache, in the fua node in the pegarules.xml file.

  • Previous topic How to discover the most frequently-executed RA rules
  • Next topic Preassembling rules in an application by using the Static Assembler utility in PRPC 6.x and Pega 7.1

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