Improving the performance of Rule Execution Server

You can improve the performance of Rule Execution Server.

You improve the performance by designing and creating efficient rulesets and tuning the application server. You create efficient rulesets when you develop a business rule application. You tune your application server when you set up your production server. The goal of performance tuning is to decrease the amount of time and resources that your application server requires to process requests. Performance tuning allows your application server to complete more tasks in less time.

Improving performance during development

During the development phase of your application, you can enhance the performance of ruleset execution by creating efficient artifacts and choosing the execution mode for your artifacts.

The following table describes how to optimize the performance by creating more efficient artifacts.

Development artifact	Recommendation
Executable object model (XOM)	The size of the Java™ XOM deployed in your EAR affects ruleset parsing and execution. To improve performance, design the class loader to be as small as possible. Include only the JAR files that hold classes that are directly called by the XOM in the managed XOM persistence.
Ruleset size	The size of a ruleset affects the total execution time. The time to generate a trace. The time to store a trace. The main cause of resource usage when generating a RuleApp archive is the number and size of rule artifacts that are deployed as part of the RuleApp. Business rule applications work better if you limit the size of the resources that are deployed to the execution environment.
Ruleset resources	To reduce the resource usage cost of a business rule application: Transform each large rule project into several smaller ones. Generate multiple smaller rulesets from each rule project. Use ruleset extractors, one per ruleset, to extract part of the rule project. In this case, you might have to change the application that executes the rulesets.
Threads	The Java XOM must be thread-safe. The Java XOM must implement the Serializable API if you call the Rule Execution Server remotely. The toString method performance can have a huge influence if you run an execution trace with the trace filter setInfoBoundObjectByRule set to `true`.
XML XOM	Configure rulesets that use an XML XOM to run in multiple simultaneous executions. Set the ruleset.xmlDocumentDriverPool.maxSize ruleset property to configure the execution pool of the XML document drivers. The default value is 1.
Ruleflow	Keep ruleflows simple. Complex ruleflows reduce performance.
Rule tasks	Avoid dynamic filters in rule tasks. Use a fixed list of rules where possible.
Decision tables	Verify the size of the decision table in the Rule Designer technical view. Dividing a decision table into several smaller tables can reduce the size of the ruleset significantly.

For more information about the artifacts that can affect performance, see Rule Execution Server administration artifacts.

You can optimize the performance in specific circumstances by choosing an appropriate execution mode. For more information about execution modes, see Choosing an execution mode.

Improving performance at run time

After you develop the application and deploy to an application server, a number of configuration steps can affect performance.

Configuration of	Recommendation
Rule Execution Server log	Verbose logs consume resources and reduce performance. Set the log level to SEVERE or WARNING in the production environment. This property is set in the Rule Execution Server ra.xml resource adapter file.
Rule session factory	If the rule session factory is unique and shared, a JNDI lookup is run once for each factory creation. A rule session factory must be unique and shared between HTTP sessions.
Class path	An increased number of JAR archives loaded by the JVM reduces performance. Use only the latest rule session libraries in your class path.
Garbage collector	On the IBM® JVM, the gencon garbage collector policy has good results on small and medium applications. Tune the garbage collector and memory size.
Ruleset update	Rulesets that are built with the decision engine require the loading of Java classes only. The rules are already compiled to executable code before deployment.
Traces	Execution without traces is the optimal mode in terms of memory usage and performance. For best performance, turn off the traces. When you choose to run the engine with a trace, the following side effects might impair performance: Memory usage increases as the execution trace is generated, the list of rules and tasks is cached, and the rule events are generated. The response of the execution takes longer when the execution trace is integrated. The size of the execution trace depends on the number of rules and tasks in the ruleset. Filtering the trace reduces the size of the trace and the time taken to generate it. Use the execution trace and Decision Warehouse only if it is mandatory. The toString method can affect the performance if you call an execution trace with the trace filter setInfoBoundObjectByRule set to true.
Execution unit (XU) pool	Each rule session is associated with an XU connection. The maximum number of concurrent rule sessions depends directly on how the XU connection pool is set up. Java SE In Java SE rule sessions, the connection pool is implemented by the XU and you can tune it in the ra.xml deployment descriptor file of the resource adapter. Java EE In Java EE rule sessions, the connection pool is provided by the application server. When Rule Execution Server is deployed on a Java EE environment, rule engines are made available through a resource adapter of the Java EE Connector Architecture (JCA). In JBoss, however, you tune the connection pool in the ironjacamar.xml file. For information about how to set or change the size of the pool, see the documentation of your application server. Configuring the XU connection pool For more information about connection pool configuration and performance, see Rule session tuning. Knowing the optimal pool size The optimal XU pool size depends on the number of possible concurrent connections and the number of rulesets to execute. Calculating the correct value of the pool size is not easy because you must consider many factors such as the size of rulesets, the number of rules, and other deployed applications and their loads. For more information about how to calculate the optimal pool size, see Rule Execution Server engine pool sizing. For more information about setting the optimal XU pool size, see Ruleset parsing and the ruleset cache. Changing the XU connection pool setting in Java SE Important: For Java SE, you must add timeout for the pool. See the following example of the ra.xml file: `<config-property> <config-property-name>defaultConnectionManagerProperties</config-property-name> <config-property-type>java.lang.String</config-property-type> <config-property-value>pool.maxSize=50,pool.waitTimeout=3000</config-property-value> </config-property>` For information about how to change the parameters of the connection pool in Java SE, see Changing connection pool settings in Java SE. XU configuration properties For more information about the XU configuration properties, see Configuration properties for execution units.
Java 2 Security	Enabling Java 2 Security decreases performance. You can tune your security configuration to minimize this effect. You can integrate Java 2 Security to the secure mode of the application server, but it is not mandatory. If Java 2 Security is enabled and an application is not prepared for it, the application is likely to run incorrectly and cause Java 2 Security access control exceptions at run time. For best performance, turn off Java 2 Security, especially on the Java Platform, Enterprise Edition.