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 |
|---|
- WebSphere® Application
Server 8.5
and 8.5.5
- WebLogic 11g (10.3.6) and 12c
|
Use the work manager that is associated with
the Decision Runner web application to set the maximum number of concurrent
threads that are used by simulations. Note: To represent accurately
the maximum number of concurrent threads that are used by the Decision
Runner, the bounded work manager must work with only the Decision
Runner. Otherwise, the number of maximum threads must be set much
higher than the required amount to accommodate requests from other
components.
|
- Tomcat 7
- JBoss 6.1 and 6.3
|
Edit the THREADPOOL_MAXIMUM_SIZE parameter
in the web application deployment descriptor (web.xml)
of the Decision Runner application. The default value is 20. |
|
|
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 Liberty use
the 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 WebSphere Application
Server, WebLogic Server and
JBoss, follow the steps for Java EE. For Tomcat and 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.