You improve the performance of simulation runs in the Business
console.
Before you begin
The Business console runs simulations on the Decision Runner
web application. A simulation can run on one or more threads, and
run a ruleset multiple times, requiring an execution unit (XU) (see Execution unit (XU)).
You can change Decision
Runner and XU parameters to make simulations more efficient:
- Decision Runner: Change the maximum number of concurrent threads.
- XU: Change the connection pool size and the connection pool wait
policy.
About this task
To complete this task, you must first estimate the maximum
number of single-threaded simulations (X) and multithreaded
simulations (Y) that might be started in parallel, and the
maximum number of threads that might be used for multithreaded simulations
(Z). Use this formula to determine the maximum number of concurrent
threads: X + (Y x Z).
Procedure
- Change the maximum number of concurrent threads in the
Decision Runner on your server:
| Application server |
Method |
|
|
Edit the THREADPOOL_MAXIMUM_SIZE parameter
in the web application deployment descriptor (web.xml)
of the Decision Runner application. The default value is 20. |
| WebSphere
Liberty
profile |
You cannot set the maximum number of concurrent
threads for simulations directly on the executor service that is associated
with the Decision Runner web application. Executor services on WebSphere
Liberty use
the WebSphere
Liberty common
thread pool. If necessary, you can tune the maximum number of threads
directly on the common thread pool. Note that the common thread pool
is shared, and its threads are not used by the Decision Runner only. |
- Set the connection pool size for the XU. Change the size
to be in line with the capacity of the server and greater than the
maximum number of concurrent threads.
If you cannot
set the connection pool size to be greater than the maximum number
of concurrent threads, you must lower your estimate. For best results,
dedicate a XU to simulations. If other applications must use the XU,
try to use a number of connections greater than the maximum number
of concurrent threads.
Note: For more information about customizing the connection pool of a XU, see Rule session tuning. For JBoss, follow the steps for Jakarta EE. For Tomcat and WebSphere
Liberty, follow the steps for Java™ SE.
- Set the connection pool wait policy for the XU so that
the connection pool refuses new connections immediately when the pool
is full. If simulations fail, check your application server logs for
the following Decision Runner error:
GBRXU200E: The default connection manager pool is full.
If you get this message, increase the connection pool size
to try to solve the problem.
Alternatively, depending on the
application server, you can change the connection pool wait policy
so that the connection pool is able to wait for a connection to be
released to fulfill a connection request when the pool is full. However,
if the wait time is set to an indefinite amount of time, it might
cause some threads to hang in the system.
Example
In setting up the Decision Runner, you determine that
you must be able to run at the same time 10 single-threaded simulations
and 4 multithreaded simulations that have a maximum of 8 threads each.
The maximum number of concurrent threads comes to 10 + (4 x 8) = 42.
You
have a server that can handle a connection pool size of 60. The XU
is shared, but the other applications take no more than 10 connections
at the same time, so we have 50 connections available for simulations.
Using
these parameters, you can have up to 8 more single-threaded simulations
when compared to the estimated simulation load (50 - 42 = 8), or you
can have more than 8 threads for some multithreaded simulations, at
full performance and without getting failures. If you exceed these
parameters, the connection pool wait policy might make new simulations
and some existing running simulations fail.