Parallel processing

The testSuite thread pool must be sized in relation to the resource capabilities of the Decision Center server on which the pool runs. The available CPU and memory must be sized to accommodate the rulesets that need to be built.

Building a ruleset can draw heavily on machine resources because, for example, every rule artifact must be retrieved and compiled. Although the compiled rules are cached, this compilation process is CPU intensive, and archiving all the rule artifacts is done in memory. Depending on the number of artifacts involved in a ruleset, the higher the number of artifacts, the greater the CPU and memory consumption when it comes to building and archiving a ruleset.

When launching multiple test suites, parts of these test suites are processed in parallel, including test suite ruleset building and launching on decision runner along with ruleset deployment. Any remaining test suites to be run are queued until other test suite preparation is finished. This parallelism is achieved by using a thread pool.

Reasons to use a thread pool:

Launching an unlimited number of test suites on a single machine isn't possible.
Pooling works well when resources are scarce or bounded.
The size of the thread pool can be changed, providing flexibility for many different needs.

Setting the size of the testSuite thread pool

Setting the thread pool size can be done in two ways:

Dynamically with a custom Operational Decision Manager parameter. This can be changed at any time but is taken into account when no tests are running.
The setting key is decisioncenter.testsuites.threadpool.size.
Statically with a System Wide parameter that is set on the Java virtual machine (JVM). The value can only be changed when the server is down. Using a System Wide parameter overrides the custom Operational Decision Manager setting.
Example of a System Wide parameter: -Ddecisioncenter.testsuites.threadpool.size=8

If no value is set either ways, the default value 1 is used. Then, you get the usual behavior of one build at a time.

The global setting can be edited in the Decision Center Business console in the Administration > Settings page. You can define the custom setting decisioncenter.testsuites.threadpool.size.

Special considerations about sizing

In sizing the thread pool, great care must be taken as there is no rule of thumb for this task. Careful JVM monitoring, as well as common sense, provide the insight for sizing the thread pool. For example, if there are too many threads in the pool and the CPU consumption is too high, the server slows down significantly and might affect the garbage collection process and generate memory exception faults. This is because the process of building and compiling a ruleset uses a lot of CPU, and building an archive uses a lot of memory as well. The server is affected by the amount of ruleset building and archiving done simultaneously because it affects CPU and memory performance. This is normal and expected.

In addition, if the rulesets include numerous rules with large decision tables, CPU and memory usage for building the ruleset archive becomes more intensive.

When CPU and memory usage becomes excessive, the following error can occur:

java.lang.OutOfMemoryError: GC Overhead Limit Exceeded

This error is displayed when garbage collection is no longer efficient. It results from two different factors:

Too much data to garbage collect.
Not enough time to do the garbage collection in a timely manner.

It might be necessary to increase memory settings first to avoid primary issues when CPU usage gets high. Then, if this memory error persists, you might need to set the garbage collection settings so that garbage collection is done in a more timely manner. The number of garbage collection threads is worth checking.