IBM WebSphere ILOG JRules Minimizing the effect of ruleset parsing on the performance of Rule Execution Server

November 2009

IBM

IBM WebSphere ILOG JRules Minimizing the effect of ruleset parsing on the performance of Rule Execution Server
Technical White Paper Version 1.4

YeePin Yheng
Product Manager - Enterprise Integration for WebSphere ILOG BRMS, Application and Integration Middleware Software, IBM Software Group

IBM WebSphere ILOG JRules Minimizing the effect of ruleset parsing on the performance of Rule Execution Server

Page 2

Contents Introduction Avoiding redundant ruleset reparsing Warming up a ruleset 2 3 4

Introduction When a ruleset that has been deployed on Rule Execution Server is invoked, the first execution takes longer than subsequent ones. This difference is due to the parsing time. Rulesets contain artifactssuch as the Business Object Model (BOM), the executable ILOG Rule Language (IRL) and the mapping between the BOM and the executable object model (B2X mapping)that must be parsed before the Rule Engine can execute them. A parsed ruleset is stored in a cache in Rule Execution Server (RES) and shared between different client sessions so that subsequent executions of the ruleset do not require reparsing. This architecture improves the performance of concurrent executions. The on-demand behavior also allows many ruleset versions to be available for execution without having all of them loaded in memory. However, when rulesets get bigger because the number of rules increases, the time spent parsing the rulesets becomes longer and can adversely affect your business. Therefore, it is recommended that you avoid ruleset parsing whenever possible. Ruleset parsing occurs in the following cases:
1. 2. The ruleset is parsed the first time it is called because the cache is empty. During non-peak hours, free Execution Unit (XU) connections can be garbage-collected if they remain idle for longer than the unused timeout value defined on the connection factory. When the last connection that references the ruleset in the cache is released, the ruleset might be removed from the cache. As a result, the ruleset has to be parsed again the next time it is called. 3. When a new ruleset is updated, whether you replace or increase the ruleset version, the ruleset has to be parsed again the next time it is called. 4. Another case is when the number of active rulesets is greater than the size of the XU connection pool or when one ruleset is called more frequently than the others. For example, let us suppose that the maximum number of connections defined on the Connection Factory is three and the following rulesets are loaded in memory:

Setting up a ruleset warming application in a cluster 4 Using asynchronous parsing for hot deployment Retrieving ruleset caching details from the Rule Summary 10

IBM WebSphere ILOG JRules Minimizing the effect of ruleset parsing on the performance of Rule Execution Server

Page 3

exampleRuleApp\1.0\Pricing\3.0 exampleRuleApp\1.0\Eligibility\3.0 exampleRuleApp\1.0\Datavalidation\3.0

If the Pricing ruleset is called more frequently than the Eligibility and Datavalidation rulesets, it is likely that the Pricing ruleset dominates the connection pool and that the Eligibility and Datavalidation rulesets have to be reparsed.

As a consequence, to optimize the performance of Rule Execution Server:

Avoid unnecessary ruleset reparsing. Avoid blocking concurrent client requests when a more recent version of the ruleset gets deployed. Be ready to receive client requests as soon as a ruleset is deployed. The client request must not wait for the ruleset to be parsed.

This white paper describes techniques to achieve this goal. Avoiding redundant ruleset reparsing If a ruleset is not executed very frequently (the interval between any two subsequent calls is longer than the connection unused timeout value), the cached ruleset might be garbage-collected by the application server. You can increase the Aged Timeout value and the unused Timeout value of the Connection Pool Settings of the connection factory (XU) to ensure that the parsed ruleset stays cached in the connection pool. Set the Aged Timeout value to zero to make the active physical connection remain in the pool indefinitely. Be aware that if your ruleset is large and you have many active rulesets, you might encounter memory issues because cached rulesets are seldom garbage-collected. In this case, you need to create more than one server and dedicate a server to each ruleset. If you notice that some rulesets get parsed more than once, this might point to Case 4 described in the Introduction: the cached rulesets are garbage-collected because of the maximum pool size limitation and the fact that the other rulesets are called more frequently. In this case, you can assign a dedicated connection factory to each ruleset or use different servers (JVM) for these rulesets to ensure proper isolation so that the call of a ruleset does not influence another.

IBM WebSphere ILOG JRules Minimizing the effect of ruleset parsing on the performance of Rule Execution Server

Page 4

Warming up a ruleset You can create a scheduled task which submits a request to parse a ruleset during non-peak hours. The purpose of this task is to warm up the ruleset to make it ready for upcoming calls, so that the client does not need to wait until parsing is finished. With WebSphere ILOG JRules 7.0, you can use the following API to force ruleset parsing:
IlrSessionFactory sessionFactory = new IlrPOJOSessionFactory(); sessionFactory.createManagementSession().loadUptodateruleset(IlrPath.parsePath(/exampleRuleApp/Pricing));

Prerequisite: Ruleset parsing requires the Execution Object Model (XOM) Java classes that are provided through the class loader of the calling client application. Therefore, the client application must include the XOM. This is not necessary if your ruleset is based on XSD object model. Setting up a ruleset warming application in a cluster Rulesets need to be warmed up in each server where the XU is deployed because the parsed rulesets are cached in the resource adapter instance. Therefore, the startup application must also be installed on each server.

IBM WebSphere ILOG JRules Minimizing the effect of ruleset parsing on the performance of Rule Execution Server

Page 5

In some cases, a scheduled task might not be able to meet the service-level requirement. One example is when it is necessary to warm up a ruleset immediately after it is deployed. With the scheduled task approach, there might be a delay between the time when the ruleset is deployed and the time when the ruleset gets warmed up. To solve this problem, you can create a startup application to receive the JMX notifications from the RES Console whenever a ruleset is changed. The application then invokes the ruleset by calling a remote rule session EJB. You need to deploy one Rule Session EJB on each server where the XU is deployed. In other words, if you have three XU instances, you must deploy three Rule Session EJBs. The startup application must call the three EJBs when the rulesets are modified. The following diagram shows the reference architecture on which you can implement such a solution. Using asynchronous parsing for hot deployment The asynchronous ruleset parsing feature in JRules 7.0 allows client applications to continue to submit rule execution requests which use the previously parsed ruleset, while a newer version of the ruleset is being parsed. The following diagram shows what happens when a ruleset is deployed in JRules versions earlier than 7.0. The horizontal axis indicates the timeline.

IBM WebSphere ILOG JRules Minimizing the effect of ruleset parsing on the performance of Rule Execution Server

Page 6

When the first ruleset (noted as V1) is deployed to RES, the next request (Request 1) triggers the parsing of this ruleset. The parsing time is shown in grey. Request 1 is completed only after the ruleset has been parsed. When Request 2 comes in, it takes much less time because the ruleset has already been parsed. When a newer version of the ruleset (noted as V1) is deployed, the next request (Request 3) triggers parsing of V1. Until VI has been parsed completely, other concurrent requests, such as Requests 4 and 5, are blocked. During this delay business opportunities can be lost. The following diagram shows what happens when a ruleset is deployed in JRules 7.0 and higher. The horizontal axis indicates the timeline.

IBM WebSphere ILOG JRules Minimizing the effect of ruleset parsing on the performance of Rule Execution Server

Page 7

In the same deployment scenario, with the asynchronous parsing feature implemented in JRules 7.0, the first request triggers parsing of ruleset V1. The parsed ruleset is cached. When a new ruleset is deployed to RES, Request 3 triggers the parsing process. The new ruleset V1 is parsed in the background. Request 3 uses the previously parsed ruleset V1. Other concurrent requests, R4 and R5, also use the previously parsed ruleset V1 until the newer version of ruleset V1 is completely parsed. To turn on this feature, set the asynchronousRulesetParsing property to true in the ra.xml file located in the META-INF folder of jrules-res-xu-xxx.rar file before you deploy the XU. From the client perspective, with asynchronous parsing, the parsing phase takes virtually no time because the Execution Unit carries out the parsing process in a new, separate thread. Note, however, that parsing is very resourceintensive and consumes significant CPU power. As a result it might slow down other concurrent calls.

IBM WebSphere ILOG JRules Minimizing the effect of ruleset parsing on the performance of Rule Execution Server

Page 8

Retrieving ruleset caching details from the Rule Execution Server Console You can get detailed ruleset caching information (Execution Unit dump) from the RES Console: how many free connections there are in the pool, which rulesets have been parsed, how much free memory is left, and so on. To access ruleset caching information:
1. Change the Log Level in the RES Console to Debug.

2.

Navigate to the Execution Unit you want to investigate.

IBM WebSphere ILOG JRules Minimizing the effect of ruleset parsing on the performance of Rule Execution Server

Page 9

3.

Click View.

You can see which rulesets have been parsed and are stored in the cache. The following picture shows that two rulesets are currently stored in the cache.

IBM WebSphere ILOG JRules Minimizing the effect of ruleset parsing on the performance of Rule Execution Server

Page 10

Summary This document describes the scenarios in which ruleset parsing occurs and how ruleset parsing affects your business application. The document also describes techniques you can adopt in your organization to make sure that ruleset parsing does not adversely affect the user experience or the performance of your client application.

Copyright IBM Corporation 2009 IBM Corporation Software Group Route 100 Somers, NY 10589 U.S.A. Produced in the United States of America November 2009 All Rights Reserved IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol ( or ), these symbols indicate U.S. registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at Copyright and trademark information at ibm.com/legal/copytrade.shtml Other product, company or service names may be trademarks or service marks of others. IBM assumes no responsibility regarding the accuracy of the information provided herein and use of such information is at the recipients own risk. Information herein may be changed or updated without notice. IBM may also make improvements and/or changes in the products and/or the programs described herein at any time without notice. References in this publication to IBM products and services do not imply that IBM intends to make them available in all countries in which IBM operates.

Recyclable, please recycle.

WSW14089-USEN-01