Improving the performance of Decision Center

You can improve the performance of Decision Center by adapting the architecture to suit your usage.

The goal of performance tuning is to decrease the amount of time and resources that your application server requires to process requests.

Improving performance when Decision Validation Services is not enabled

Decision Center is a high consumer of CPU, memory, and database resources. To ensure scalability, set up the hardware architecture to support usage requirements.

Development item	Recommendation
Hardware architecture and CPU usage	Decision Center is designed to be accessed by several users at the same time. Each time a user accesses the Decision Center URL an HTTP session is created on the server and is filled with several objects during the session, including the current IlrSession, some Java™ beans to support the model of the JSF components used in the interface, and some Web components (Intellirule editor and decision table editor). The memory footprint required for a session is difficult to estimate because it depends on many factors, including what actions are performed through the GUI, the VM, and the structure of the repository. If the number of users connected simultaneously to a single server does not fit into the memory allocated for a single VM, deploy Decision Center to a cluster of servers and use load-balancing, so that HTTP sessions are dispatched according to the available memory of the server. The number and size of the vocabularies used in a Decision Center repository can also effect memory usage. The first time the vocabulary of a given project is loaded, it is stored in memory and shared across sessions. By default, vocabularies are stored in a pool of 10 instances. After 10 instances, other vocabularies are soft-referenced so that the virtual machine can free memory. The same pooling algorithm applies to instances of BOMs and variable providers. According to the number of users using Decision Center and the kinds of operations they perform, the number of CPUs can be a critical resource. Parsing a business rule or event rule is an atomic operation, which takes a lock on the vocabulary instance to be used. Long running operations such as ruleset generation and reporting make heavy use of the CPU. This means that if many users are accessing the same project at the same time, and they perform long operations, the shared vocabulary can become a bottleneck. This reinforces the need to deploy Decision Center on a cluster.
Database access	Most Decision Center operations perform SQL queries. In the case that queries consume too much time, deploy the application server and the database on different computers to force the distribution of the load between Java computing and database access. This should improve the user experience when multiple users are connected to the repository. You can also set the JDBC connection pool of the data source to a number that is equivalent to the maximum number of users that simultaneously connect to Decision Center. If the pool is too small, users may end up getting connection time-outs when their sessions are trying to access the database.
Queries in rule projects	To reduce the time taken to run a semantic or rule analysis query, you can add conditions on the metadata. For example: find all business rules such that each business rule is never applicable and the status of each business rule is 'deployable'

Development item

Recommendation

Hardware architecture and CPU usage

Decision Center is designed to be accessed by several users at the same time. Each time a user accesses the Decision Center URL an HTTP session is created on the server and is filled with several objects during the session, including the current IlrSession, some Java™ beans to support the model of the JSF components used in the interface, and some Web components (Intellirule editor and decision table editor). The memory footprint required for a session is difficult to estimate because it depends on many factors, including what actions are performed through the GUI, the VM, and the structure of the repository. If the number of users connected simultaneously to a single server does not fit into the memory allocated for a single VM, deploy Decision Center to a cluster of servers and use load-balancing, so that HTTP sessions are dispatched according to the available memory of the server.

The number and size of the vocabularies used in a Decision Center repository can also effect memory usage. The first time the vocabulary of a given project is loaded, it is stored in memory and shared across sessions. By default, vocabularies are stored in a pool of 10 instances. After 10 instances, other vocabularies are soft-referenced so that the virtual machine can free memory. The same pooling algorithm applies to instances of BOMs and variable providers.

According to the number of users using Decision Center and the kinds of operations they perform, the number of CPUs can be a critical resource. Parsing a business rule or event rule is an atomic operation, which takes a lock on the vocabulary instance to be used. Long running operations such as ruleset generation and reporting make heavy use of the CPU. This means that if many users are accessing the same project at the same time, and they perform long operations, the shared vocabulary can become a bottleneck. This reinforces the need to deploy Decision Center on a cluster.

Database access

Most Decision Center operations perform SQL queries. In the case that queries consume too much time, deploy the application server and the database on different computers to force the distribution of the load between Java computing and database access. This should improve the user experience when multiple users are connected to the repository. You can also set the JDBC connection pool of the data source to a number that is equivalent to the maximum number of users that simultaneously connect to Decision Center. If the pool is too small, users may end up getting connection time-outs when their sessions are trying to access the database.

Queries in rule projects

To reduce the time taken to run a semantic or rule analysis query, you can add conditions on the metadata. For example:

find all business rules
such that each business rule is never applicable
and the status of each business rule is 'deployable'

Improving performance when Decision Validation Services is enabled

If you have enabled Decision Validation Services, you can improve the performance of testing and simulating in the Decision Center Enterprise console in the following ways:

Development item	Recommendation
CPU and memory	To improve the performance of Decision Validation Services, install the instances of Rule Execution Server and Decision Center you use to run your tests on different computers. This separation reduces the impact on Decision Center resources (CPU and memory) when Rule Execution Server consumes resources executing a test suite or a simulation.
Rule Execution Server	Each time a test suite is run from the Enterprise console, a new RuleApp is created, deployed, and parsed to Rule Execution Server. This means that the parsing cost on Rule Execution Server cannot be avoided. Therefore dedicate a Rule Execution Server instance to testing rules.
XU pool	Set the size of the XU pool to a size that is smaller than the total available memory divided by the maximum amount of memory of a ruleset (set in the ra.xml file of the SSP, or configured in the JCA connection factory of the application server). If you have 1 GB allocated for your VM and you execute a ruleset that takes 300 MB in memory, the size of the pool for the XU must be less than or equal to 4. 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.
SSP pool	Set the size of the SSP pool to half the size of the XU pool (`JRULES_JOBS_POOL_SIZE` in the web.xml of the SSP WAR). Running a test suite creates two rulesets on Rule Execution Server, so the size of the SSP pool can reduce the risk of overloading the XU pool unnecessarily, and eliminates the possibility of a bottleneck for test suite or simulation executions. Note: This feature is not available on WebSphere Application Server.