此内容没有您所选择的语言版本。
Chapter 89. Performance tuning considerations with the decision engine
The following key concepts or suggested practices can help you optimize decision engine performance. These concepts are summarized in this section as a convenience and are explained in more detail in the cross-referenced documentation, where applicable. This section will expand or change as needed with new releases of Red Hat Process Automation Manager.
- Use sequential mode for stateless KIE sessions that do not require important decision engine updates
Sequential mode is an advanced rule base configuration in the decision engine that enables the decision engine to evaluate rules one time in the order that they are listed in the decision engine agenda without regard to changes in the working memory. As a result, rule execution may be faster in sequential mode, but important updates may not be applied to your rules. Sequential mode applies to stateless KIE sessions only.
To enable sequential mode, set the system property
drools.sequential
totrue
.For more information about sequential mode or other options for enabling it, see Section 84.3, “Sequential mode in Phreak”.
- Use simple operations with event listeners
Limit the number of event listeners and the type of operations they perform. Use event listeners for simple operations, such as debug logging and setting properties. Complicated operations, such as network calls, in listeners can impede rule execution. After you finish working with a KIE session, remove the attached event listeners so that the session can be cleaned, as shown in the following example:
Example event listener removed after use
Listener listener = ...; StatelessKnowledgeSession ksession = createSession(); try { ksession.insert(fact); ksession.fireAllRules(); ... } finally { if (session != null) { ksession.detachListener(listener); ksession.dispose(); } }
For information about built-in event listeners and debug logging in the decision engine, see Chapter 87, Decision engine event listeners and debug logging.
- Configure
LambdaIntrospector
cache size for an executable model build -
You can configure the size of
LambdaIntrospector.methodFingerprintsMap
cache, which is used in an executable model build. The default size of the cache is32
. When you configure smaller value for the cache size, it reduces memory usage. For example, you can configure system propertydrools.lambda.introspector.cache.size
to0
for minimum memory usage. Note that smaller cache size also slows down the build performance. - Use lambda externalization for executable model
Enable lambda externalization to optimize the memory consumption during runtime. It rewrites lambdas that are generated and used in the executable model. This enables you to reuse the same lambda multiple times with all the patterns and the same constraint. When the rete or phreak is instantiated, the executable model becomes garbage collectible.
To enable lambda externalization for the executable model, include the following property:
-Ddrools.externaliseCanonicalModelLambda=true
- Configure alpha node range index threshold
Alpha node range index is used to evaluate the rule constraint. You can configure the threshold of the alpha node range index using the
drools.alphaNodeRangeIndexThreshold
system property. The default value of the threshold is9
, indicating that the alpha node range index is enabled when a precedent node contains more than nine alpha nodes with inequality constraints. For example, when you have nine rules similar toPerson(age > 10)
,Person(age > 20)
, …,Person(age > 90)
, then you can have similar nine alpha nodes.The default value of the threshold is based on the related advantages and overhead. However, if you configure a smaller value for the threshold, then the performance can be improved depending on your rules. For example, you can configure the
drools.alphaNodeRangeIndexThreshold
value to6
, enabling the alpha node range index when you have more than six alpha nodes for a precedent node. You can set a suitable value for the threshold based on the performance test results of your rules.- Enable join node range index
The join node range index feature improves the performance only when there is a large number of facts to be joined, for example, 256*16 combinations. When your application inserts a large number of facts, you can enable the join node range index and evaluate the performance improvement. By default, the join node range index is disabled.
Example
kmodule.xml
file<kbase name="KBase1" betaRangeIndex="enabled">
System property for
BetaRangeIndexOption
drools.betaNodeRangeIndexEnabled=true