By ODM performance architects: Pierre-Andre Paumelle and Nicolas Peulvast
There are significant performance gains to be had by tuning certain aspects of Rule Execution Server. The decision engine improvements made in 8.9 has much better performance compared to previous releases, and especially compared to the classic rule engine. If you switch to the decision engine in 8.9, you will see major improvements in throughput, loading times, memory consumption, and scalability.
By tuning Rule Execution Server you can further decrease the amount of time and resources that are required to execute your rules.
The checklist is divided into sections to help you locate where the optimization can be done.

Execution unit properties

Trace level

On WebSphere Application Server and JBoss, the execution units are logged by the Java logger. On other application servers, the execution unit uses the logging service of the Java Connector Architecture (JCA).
The resource adaptor (ra.xml) traceLevel and traceAutoFlush properties control the XU logging with JCA. For the Java logger, you can change the log level through the Java logging options in the administration console.
In both cases, set the trace level to Severe or Warning.

Connection pool size

The optimal pool size depends on the number of possible concurrent connections and the number of rulesets to execute. Take a measurement with the default size, and then increase it until you reach the memory limit. It’s never easy to calculate the correct size, bacause it depends on many things. The easiest way is to simulate the load and to try different values. For more information on sizing a pool, see http://www-01.ibm.com/support/docview.wss?uid=swg21400803.
If a ruleset is used infrequently, it is removed from the pool. You can prevent the removal of a ruleset by setting the minimum time it stays in memory.
Set the value of the ruleset.maxIdleTime property to 0, or to a number of seconds greater than 0. The following screen capture shows a maxIdleTime property on a ruleset.

If a ruleset is called when it is no longer in the pool, it is parsed again. The pool size must be configured in every application (HTDS and the client application).

Ruleset parsing

Parsing occurs during the first invocation of a ruleset. To minimize the effect of parsing, call the loadUptodateRuleset method of the Management Session API.
When you deploy a new version of a ruleset, a parse is launched. Parsing can block the execution. The default behavior ensures that a ruleset can be executed based on its previous version, if a version exists in the cache.
You can change this default behavior by turning off the asynchronousRulesetParsing property. Turning this property off alters the behavior to execute the newly deployed ruleset version.
Note: asynchronousRulesetParsing is a global property of the execution unit, which affects all rulesets.

Java virtual machines

Using the classic rule engine

Set the initial heap size to 1.2 GB per server for 32 bit systems, and 4GB to 8GB per server for 64 bit systems.
Set the garbage collector policy to gencon. If you have more than 6 cores, limit the number of threads for the garbage collector:
-Xgcpolicy:gencon -Xgcthreads6
The JVM supplied with WAS 8.0.0.5+, generates more JIT code than previous versions, which can lead to longer warm-up times and lower throughput. The JIT can take time to compile a large ruleset. To resolve this performance issue, increase the cache or limit the inlining of ODM classes.
-Xjit:codeTotal=261072 compilationThreads=1 – Cache size and number of compilation threads.
-Xjit:{ilog/rules/engine/Sequential/generated/*}(disableInlining) – Limit the inlining for one of the ODM packages.

Using the decision engine

Set the initial heap size to 1GB per server. Java2security should be off, especially on Java EE.
Set the garbage collector policy to gencon. If you have more than 6 cores, limit the number of threads for the garbage collector:
-Xgcpolicy:gencon -Xgcthreads6
If you do not need assertions then disable the feature in the VM arguments:
-da or -da:com.ibm.rules.*

Rule session settings

Check the version of your rule session library, disable Java2security (if possible), and verify that your application server is not in debug mode.
If you have not implemented any ruleset interceptors, set the enableInterceptor flag to false. This property is accessible in the resource adaptor (ra.xml) file.
Configure rulesets that use an XML XOM to run in multiple simultaneous executions. The setting can be done at two levels:

• By configuring the pool of the XML document driver of a ruleset. This is configured using the ruleset property ruleset.xmlDocumentDriverPool.maxSize. By increasing the value of this property, you can significantly increase the performance of ruleset execution. The default value is 1.
• By configuring the connection factory property documentBuilderPoolProperties with a pool.maxSize value to something like 20. The default value is 10. For more information, see Rule session tuning.

Download an XU dump from the RES console to see the XU settings, the ruleset caches, and the state of the current connection. The XU dump can be generated every x seconds by configuring the connection factory, or adding properties to the ra.xml file in the case of Java SE.

• Set xuDumpSchedulerEnabled to true. The scheduler has an impact on performance. Enable it for debugging purposes only. A directory named xudumps stores all of the dumps. The scheduler is not working on TWAS.
• The default value for xuDumpSchedulerInterval is 10000, that is every 10 seconds.

Lastly, use the DecisionID element to identify the decision service you request. The DecisionID optimizes the response time of the request.

EJB3 security

On the client-side, you can remove all of the configuration around the security at the connection level. The following security options on the connection do not need to be set:

• java.security.auth.login.config
• com.ibm.CORBA.ConfigURL
• com.ibm.SSL.ConfigURL
• com.ibm.SOAP.ConfigURL

Change the global security on the client-side to use the following configuration:
.

Decision warehouse

The performance cost of decision warehouse depends on the following factors:

• The generation of the execution trace.
• The serialization of the input/output parameters and the serialization of the execution trace. You can remove the BOM serialization. For more information, see Optimizing Decision Warehouse.
• The database server and the network used to access it. Optimize the database to handle CLOB data, not in a generic way, but for the specific case of the ruleset.

There are two ways to filter what is stored in decision warehouse:

• Configure Decision Warehouse at a ruleset level with filter properties.
• Use the extension point to customize decision warehouse. You can define how to persist or query data, and you can also implement your own asynchronous logging of the data. An asynchronous version of decision warehouse for WAS is available at: http://www-01.ibm.com/support/docview.wss?uid=swg21433167. The implementation uses the Work Manager API to manage the insertion in the database separately from execution.

Transmission Control Protocol in Liberty

Add the soReuseAddr=”true” element in the server tcpOptions field to enable immediate rebind to a port with no active listener.
The soReuseAddr option allows your server to bind to an address, which is in a TIME_WAIT state. The socket then tells the kernel that even if this port is busy (in the TIME_WAIT state), it can be used.
The option is useful not to miss incoming connections if your server is shut down and restarted right away while sockets are still active.