2. Presentation Summary
• Many different aspects should be considered when addressing performance
questions for a business rule management system.
• With WebSphere ILOG BRMS the answers don't always come from the
engine's intrinsic capabilities, but depend upon the customer application and
the way the Rule Execution Server is leveraged.
• As rule projects grow, there are also more and more performance topics
related to other modules, such as build time in Rule Studio, memory and
CPU usage in Rule Team Server and recommendations around Decision
Validation Services usage.
• This session will describe the best practices in addressing these concerns.
• Pierre-André PAUMELLE - WebSphere ILOG BRMS Performance Architect
1
3. BRMS overview
Business Rule Application Development Business Rule Management and Authoring
Architect/Developer/Business Analyst Business Analyst / Policy Manager / Administrator
Design
Design
Orchestrate
Orchestrate Author
Author
Synchronize
Synchronize Synchronize
Synchronize
Author
Author Review
Review
Review
Review
Validate Author
Author
Debug Validate
Debug
Review
Review
Deploy
Deploy Enable
Enable Deploy
Deploy
Test
Test
Integrate
Integrate
Monitor
Monitor
Audit
Audit
Decision Validation Services Rule Execution Server
Enterprise Applications
Architect / Developer / Administrator
2
4. Rule Studio (Authoring)
Business Rule Application Development Business Rule Management and Authoring
Architect/Developer/Business Analyst Business Analyst / Policy Manager / Administrator
Design
Design
Orchestrate
Orchestrate Author
Author
Synchronize
Synchronize Synchronize
Synchronize
Author
Author Review
Review
Review
Review
Validate Author
Author
Debug Validate
Debug
Review
Review
Deploy
Deploy Enable
Enable Deploy
Deploy
Test
Test
Integrate
Integrate
Monitor
Monitor
Audit
Audit
Decision Validation Services Rule Execution Server
Enterprise Applications
Architect / Developer / Administrator
3
5. Rule Studio best practices
• Main steps in Rule Studio
– Designing Rule Project
• XOM import
• BOM/Vocabulary/B2X creation
• Ruleset parameters declaration
– Orchestrating
• Ruleflow creation
– Authoring
• Business rules creation
– Enabling Decision Validation Services
– Deployment to Rule Execution Server
– Publishing to Rule Team Server
4
6. Rule Studio best practices
• XOM Import : Import what is necessary.
– Ex. Do not import all WAS classes if not necessary.
• BOM/VOC/B2X:
– Limit your BOM and VOC, to limit the size of the vocabulary when you edit the
rules.
– Limit the usage of “Update object state” property
– Divide your BOM through several projects by this way you can specialize the
vocabulary by rule project.
• Divide your rule application in a set of rule projects with dependencies.
• Enable Decision Validation Services before Rule Team Server Publication.
• Ruleflow:
– Limit the size of the ruleflow, it is interpreted.
– Limit the usage of dynamic filter in the rule tasks, use fixed list of rules if you
can.
– Use always the same engine algorithm to save memory
5
7. Rule Studio best practices
• Choose the correct engine algorithm depending on your
application.
– Rete plus (The default mode)
• Stateful application
• Rule chaining application
• may be useful in the case of many objects
– Sequential
• Application with many rules and few objects
• Most of the customer cases.
• Really efficient in multi-thread environment.
– Fastpath
• Application with rules implementing a decision structure and
many objects
• May have longer compilation but faster at run time.
6
8. Rule Studio best practices
• Configuration to get better build performance
– Remove the build automatically on big rule projects
– Rule Studio Menu> Windows> Preferences> Rule Studio >
Build
7
9. Rule Studio best practices
• Configuration of Decision Table
– Remove the Table Checks on Overlap and Gaps.
8
10. Rule Studio best practices
• The performance cost for a JRules application may looks
something like
Execution Time
XOM
Ruleflow
Functions
B2X
Misc. Rule engine
JVM (GC)
9
11. Rule Studio best practices
• Recommendations for avoiding performance issues in your
rule projects include:
– Consider putting continuous performance measurement in place
to provide you with a safety net as you modify your XOM and
rules. It is much easier to see the impact of adding a
synchronized method call to the XOM, or adding a rule with a
complex join if you are receiving performance or throughput
reports every morning.
– Performance test with realistic data. There is no point optimizing
for a dummy data set that bears no resemblance to what you
will see in production.
– Understand the frequency with which the methods in your XOM
are invoked by rules, particularly if you are doing lots of
inferencing using the RETE algorithm.
– Spend time optimizing your XOM where profitable.
– Spend time getting to know the features of your profiler.
10
12. Rule Team Server (Authoring)
Business Rule Application Development Business Rule Management and Authoring
Architect/Developer/Business Analyst Business Analyst / Policy Manager / Administrator
Design
Design
Orchestrate
Orchestrate Author
Author
Synchronize
Synchronize Synchronize
Synchronize
Author
Author Review
Review
Review
Review
Validate Author
Author
Debug Validate
Debug
Review
Review
Deploy
Deploy Enable
Enable Deploy
Deploy
Test
Test
Integrate
Integrate
Monitor
Monitor
Audit
Audit
Decision Validation Services Rule Execution Server
Enterprise Applications
Architect / Developer / Administrator
11
13. Rule Team Server best practices
• Main steps in Rule team Server
– Synchronization with Rule Studio
– Authoring
– Reviewing
– Governance
– Validate with Decision validation Services
– Deploy to Rule Execution Server
12
14. Rule Team Server best practices
• Limit memory consumption
– Parse a ruleset consume memory so you can disable “Archive
parsing flag” option (Project > Edit project options > Check the
ruleset archive).
– Use Automatic build to avoid a huge ruleset generation cost at
“first ruleset generation”.
– Set in preference.properties file, build.archive.storage property
to file instead of memory.
• Build performance
– Disable “Archive parsing flag”.
– Disable “Rule analysis checks”.
13
15. Rule Team Server best practices
• Database performance
– Deploy the Application Server and database on different
machines to force the distribution of the load between Java
computing and database access.
– set the JDBC connection pool of the data source to a number
that is equivalent to the maximum number of users that will
simultaneously connect to Rule Team Server.
14
16. Rule Team Server best practices
• Memory consumption estimation on a repository of 10000
business rules
– Memory foot print of a session is ~10 MB
– Ruleset generation : ~150 MB of short-lived objects created
• If you believe the number of users connected simultaneously
to a single server will not fit into the memory allocated for a
single VM, you should deploy Rule Team Server to a cluster
of servers and use load-balancing, so that HTTP sessions
are dispatched according to the server’s available memory.
15
17. Decision Validation Services (testing)
Business Rule Application Development Business Rule Management and Authoring
Architect/Developer/Business Analyst Business Analyst / Policy Manager / Administrator
Design
Design
Orchestrate
Orchestrate Author
Author
Synchronize
Synchronize Synchronize
Synchronize
Author
Author Review
Review
Review
Review
Validate Author
Author
Debug Validate
Debug
Review
Review
Deploy
Deploy Enable
Enable Deploy
Deploy
Test
Test
Integrate
Integrate
Monitor
Monitor
Audit
Audit
Decision Validation Services Rule Execution Server
Enterprise Applications
Architect / Developer / Administrator
16
18. Decision Validation Services best practices
• Main steps of Decision Validation Services usage
– Generate a ruleapp archive with the set of rules to test.
– Deploy this ruleapp to a Rule Execution Server console.
– Trigger the execution of the ruleapp on the Scenario Service Provider,
which will pass the call to the XU (Rule Execution Server).
– Get the report.
• Execution of a simulation performance cost break down
– Most of the time consumed on Rule Team Server will take place during
ruleset generation.
– The rest of the time is taken in the Rule Execution Server (Scenario
Service Provider/XU), parsing the generated archive and executing the
scenarios.
17
19. Decision Validation Services best practices
• Deploy Rule Execution Server and Rule Team Server on two
different machines, so that when Rule Execution Server consumes
some resources executing a testsuite or simulation, Rule Team
Server resources (CPU and memory) are not impacted.
• Dedicate a Rule Execution Server instance to DVS. Do not try to
use a production Rule Execution Server for DVS tests or
simulations.
• Set the size of the RES pool according to the total available
memory/maximum amount of memory of a ruleset.
– Ex. if you have one GB allocated for your VM and are executing a
ruleset that takes 300 MB of memory, the size of the pool for the RES
must be lower than or equal to four. The size of the pool must not be
under two, a test suite runs two rulesets the ruleset to test and the
ruleset that contains the tests.
18
20. Decision Validation Services best practices
• Set the size of the Scenario Service Provider pool to the
same size of the RES pool. When this is done, the RES pool
(and thus the memory of the VM) will not be overloaded
uselessly, nor will there be a bottleneck for test
suite/simulation executions.
– JRULES_JOBS_POOL_SIZE in the web.xml of the Scenario
Service Provider WAR file.
• If you have a huge volume of scenarios, the report options
usage has a great impact on performances as we use the
Decision Warehouse to store the execution results.
19
21. Rule Execution Server (Execution)
Business Rule Application Development Business Rule Management and Authoring
Architect/Developer/Business Analyst Business Analyst / Policy Manager / Administrator
Design
Design
Orchestrate
Orchestrate Author
Author
Synchronize
Synchronize Synchronize
Synchronize
Author
Author Review
Review
Review
Review
Validate Author
Author
Debug Validate
Debug
Review
Review
Deploy
Deploy Enable
Enable Deploy
Deploy
Test
Test
Integrate
Integrate
Monitor
Monitor
Audit
Audit
Decision Validation Services Rule Execution Server
Enterprise Applications
Architect / Developer / Administrator
20
22. Rule Execution Server
• Rule execution management & monitoring
– Persistence and Versioning
– Rule Execution statistics & trace
– JMX-based administration console
• High performance and scalable rule execution
– Support transactional and batch rule execution
– Pool of engines (ruleset and contexts)
– Cluster enabled
• Integrate with Java, XML & WS
• Exposes Decision services as
– Rule Session (POJO, EJB or MDB)
– Transparent Decision Services (Web Services)
– Optional execution trace or Decision Warehouse
21
23. Rule Execution Server best practices
• The log level in the Rule Execution Server should be set to
level Severe or Warning in the production environment to
increase performance. This property is accessible in the
resource adaptor of the Rule Execution Server or in the
ra.xml.
• The Rule Execution Server pool size should be tuned to have
enough connection but with a reasonable memory
consumption.
• Integrate in the classpath of your application the correct
version of the ruleSession.
• Tune the GC and memory size.
22
24. Rule Execution Server best practices
• Tune the usage of the execution trace and the Decision
Warehouse by filtering.
• Limit the size of your XOM to useful classes
• A ruleset on an XML XOM should be configured to run in
multiple simultaneous executions by configuring the pool of
XML document drivers. The ruleset property
ruleset.xmlDocumentDriverPool.maxSize configures it.
• Java2security should be off if possible especially on JEE.
• Use the ruleset caching information (XU dump) from the Rule
Execution Server console to get the Rule Execution Server
status.
23
25. Rule Execution Server best practices
• Performance of Decision Warehouse depends on:
– The execution trace generation performance
– The serialization performance, which divides into two principal
cases for the input/output parameter serialization to BOM
(depends on the size of the ruleset parameters) and the
serialization of the execution trace, which depends on the
ruleset characteristics (number of rules, number of rules fired
…)
– The performance of the database server and the network used
to access it.
24
26. Rule Execution Server best practices
• There are three main ways to optimize the Decision Warehouse:
– The Decision Warehouse is configurable at a ruleset base with filter
properties. With this, you can choose the information to save.
– The performance of the Decision Warehouse depends on the
database. For example, the database should be optimized to handle
CLOB data, not in a generic way, but for the specific case of the
ruleset.
– The Decision Warehouse is customizable. Further customization can
be done through the Decision Warehouse extension point for better
execution performance. You can define how data can be persisted or
queried through the extension point.
25
27. Rule Execution Server best practices
• The optimal RES pool size depends on the number of possible
concurrent connections and the number of rulesets to execute. The
limit is reached by the memory consumption. On a dual-core
computer, a pool size of 50 is correct.
• The following three scenarios illustrate how the performance
overhead of ruleset parsing can be minimized:
– Parsing at Rule Execution Server launch or first invocation of the
ruleset. In this case, the ruleset should be parsed before the first
execution. You can force it with a dummy execution or a call of the
loadUptodateRuleset (Management Session API).
– Update of a ruleset already in use. This can be fixed by using the
asynchronous parsing.
– A ruleset is used infrequently once a day, for example, and removed
from the pool running other rulesets. This can be fixed by setting
ruleset.maxIdleTime to 0 on this ruleset.
26
28. Rule Execution Server best practices
• Applications topologies
– JEE shared: The resource is deployed to the application server
and shared (and possibly accessed) by all the applications
deployed to the server. That is the default topology.
– JEE Isolated: The resource is deployed and scoped within a
single application.
• This is a more advanced deployment option that enables
multiple applications to be deployed to the same server, and
for each application to use completely separate versions of
ILOG JRules classes.
– JSE embedded: The resource is JSE and scoped to customer
application only JSE sessions are available.
27
29. Benchmark of Rule Execution Server
• Five sizes of ruleset from 2912 to 14450 rules
– Ruleflow and Sequential algorithms used
• Two versions of equivalent XOMs (eXecution Object Model)
– Java XOM
– XML XOM
• Three types of execution
– POJO execution
– POJO execution with trace (default filter)
– HTDS execution Web Service on XML XOM rulesets
• 35 concurrent users
28
30. Benchmark configuration
• Hardware
– X3550M2 / DESTINY (2 processors-8 cores)
• Software
– OS 64-bit Windows Server 2008 Enterprise
– WAS 7.0.x
– JRules 7.0.x
• Configuration
– Default WAS Java: -Xgcpolicy:optthruput -Xmx1024M
– J2C Connection Factory traceLevel = SEVERE
– J2C Connection Factory Connection Pool
• max connections = 50
– Java 2 Security OFF
29
31. Benchmark of Rule Execution Server
Transaction per second by ruleset size and execution type
800
700
600
500 Execution on Java XOM
Execution on Java XOM with Trace
400
Execution on XML XOM
300 Execution on XML XOM with Trace
WS Execution (HTDS)
200
Execution on Java XOM
100
Execution on Java XOM with Trace
Execution on XML XOM 0
Execution on XML XOM with Trace 2912
5824
WS Execution (HTDS) 8736
11648 Nb rules
14560
30
32. Benchmark of Rule Execution Server
Parsing time by ruleset size and execution type
50000
45000
40000
35000
30000 Execution on Java XOM
Execution on Java XOM With Trace
ms 25000
Execution on XML XOM
20000 Execution on XML XOM with Trace
15000 WS Execution (HTDS)
WS Execution (HTDS)
10000
Execution on XML XOM with Trace
5000 Execution on XML XOM
0 Execution on Java XOM With Trace
2912 Execution on Java XOM
5824
8736
11648
Nb rules 14560
31
33. Useful links
• BRMS performance Forum:
http://www.ibm.com/developerworks/forums/category.jspa?ca
tegoryID=279
• BRMS performance Red Paper
http://www.redbooks.ibm.com/abstracts/redp4632.html
32
34. BRMS performance Take away
• There are a number of different ways to configure the BRMS
modules, which might affect performance.
• Check the default settings and assessing whether you can
change parameters to get the best mix of speed and
versatility for your application.
• The performance care starts from authoring and goes to
runtime execution.
33
35. Other WebSphere ILOG BRMS Sessions
Monday Tuesday Wednesday Thursday
2140: Feedback 2203: LAB 1545: BRMS - BPM 1997: BRMS - BPM
2155: Customer 1545: BRMS - BPM 2730: BRMS - BPM 1749: Decision Services
Experience
1818: BRMS for 1736: Performance 2160: Feedback
2861: Business Agility Business Users
1547: LAB, BRMS-BPM 2140: Feedback
1809: Business/IT 1749: Decision Services
Alignment 2140: Feedback
2160: Feedback
2160: Feedback 1848: Governance
2981: Meet the Experts
2198: Live on Stage! 1922: Best Practices
1499: BRMS for z
2140: Feedback 2160: Feedback
2517: Business Agility
2291: Business Agility 2013: BOF
2140: Feedback
2927: BRMS – SOA
2160: Feedback
2885: Panel
2080: Healthcare
1734: BRMS for COBOL
* In blue – interactive / hands-on * In orange – customer speaker 34
36. We Value Your Feedback !
• Please complete the session survey for this session by:
• Accessing the SmartSite on your smart phone or computer
at: http://imp2010.confnav.com
– Surveys / My Session Evaluations
• Visiting any onsite event kiosk
– Surveys / My Session Evaluations
• Each completed survey increases your chance to win an
Apple iPod Touch with daily drawing sponsored by
Alliance Tech
35
