Performance tuning

This is undoubtedly the fastest way to access this engine, because it means a direct Java call with nothing additional between client and server.
The deployment constraint is that the client of the engine must be located in the same JVM as the engine server.

The remote access modes enable you to have an engine client connected remotely to the engine server.

All remote access modes share a set of common benefits and constraints. There is a loss of performance mainly because of serialization between client and server.
If your client is not located on the same machine than your server JVM, the network becomes an additional potential source of performance reductions to monitor.

Client threads are responsible for a large part of the load generated inside the engine.
The number of client threads is related to the number of parallel users.

If you are running your own application, you have one thread if your applicaiton is not multi-threaded, or you have the number of threads you decided to create explicitly in the application or using your own threadpool.

If you are running Bonita Engine inside a container, the maximum number of client threads is defined by a parameter of the container. For example: Apache Tomcat maxThreads set in `Tomcat_folder``/conf/server.xml`.
Default value 20.
See the Tomcat documentation for information about the maxThreads parameter.

The work service is responsible for asynchronously processing execution of process instances. The work service has its own thread pool, which can be configured for each tenant.
This is one of the key configurations to optimize, because even though there are many client threads, client threads are held only for a short time before being released, and then execution flow continues using work service threads.
A thread from the pool of the work service is known as a worker.

The work service is configured in bonita-tenant-community-custom.properties and bonita-tenant-sp-custom.properties (cf platform setup).

Community:

Subscription only:

It is very similar to the constructor provided in the default JDK ThreadPoolExecutor.
For a reminder of how the threadpool behaves, see the Queuing section of the ThreadPoolExecutor documentation.

In the default Bonita configuration, corePoolSize is equal to maximumPoolSize because we have observed that the default implementation of the threadpool executor allocates work to available threads using a round robin algorithm.
Therefore, if the maximum is reached, the thread pool size is unlikely ever to reduce to corePoolSize, because work is always allocated to available threads.
The current implementation of the RejectedExecutionHandler queues the work, and reduces the system load because it does not release the caller (normal behaviour for a BlockingQueue).

After a lot of profiling, we have concluded that having an arbitrarily high number of threads in the work service does not positively impact the performance of the whole system, because it leads to a lot of contentions, mostly on the database (see Database connections).

The size of the threadpool (corePoolSize in the default configuration) is key, and correlates to the number of process instances the engine can handle in parallel.
In other words, if you want the engine to be capable of handling X process instances concurrently, you should set the corePoolSize value of the work service to X.
You then need to ensure that your platform infrastructure can handle X concurrent instances, checking that all other engine dependencies including the network and the database are able to process all incoming requests without loss of performance.

Setting a high queueCapacity limit means that more work can be queued, but can reduce throughput as work is queued rather than causing a new thread to be created.
It is essential to ensure that the queue never becomes full (queueCapacity is never reached).
If the queue becomes full, the application restarts in order to force the engine to generate all work from the database. This means that work is lost.

The connector service executes connectors. To improve tenant isolation (and to protect against denial-of-service attacks), the default implementation of the connector service has its own thread pool and requires executes connectors in a separate thread from the worker.
The configuration of the thread pool of this service is independent of the configuration of the work service. If you have processes that use a lot of connectors, then you can have more threads to execute connectors. See the connector execution page for details on how connectors are executed.

The Connector service is configured in bonita-tenant-community-custom.properties and bonita-tenant-sp-custom.properties (cf platform setup)

Community:

Subscription only:

For details of these parameters, see Work service.

In addition, connectors longer that 10 seconds produce a log at warning level named: org.bonitasoft.engine.core.connector.impl.ConnectorExecutionTimeLogger. This log contains all references to find exactly which connector is slow.

Another log at the debug level prints all input parameters of this connector.

Here is a sample log produced using a connector that does a Thread.sleep(15000)

The 10 seconds threshold can be changed in the configuration file bonita-tenant-community-custom.properties

The Scheduler service is responsible for executing jobs.
A job is executed inside a thread of the scheduler service.
There are various kinds of jobs, some resulting from internal requirements such as API session cleaning, or batch deletion of a table row, and some related to process design such as BPMN2 events.
The Bonita Engine Scheduler service uses the Quartz Scheduler. Quartz takes the size of the threadpool as an input parameter. Quartz uses threads to execute jobs concurrently.

The Scheduler service configuration is in bonita-platform-community-custom.properties. You can configure:

Two datasources are defined:

Note that the sum of the maximum values configured for bonitaDS and bonitaSequenceManagerDS should be less than or equal to the maximum number of simultaneous connections allowed to your database.

You need to configure the maximum pool size for datasources (the following paths are for bundle users).

For Tomcat, edit the file setup/tomcat-templates/bonita.xml:

Bonita Engine manages a dedicated sequence for each table for ID generation. This implementation allows fast delivery of IDs and a single point of usage inside the application: the persistence service.

The sequence manager keeps in memory a range of reserved IDs by table.
This range size is configurable by sequence so that it can be adapted to the volume you have.
The bigger a range is, the less frequently the sequence manager will have to query the database for a new range, because it is managed in memory for as long as possible.
However, all the IDs that are reserved in memory are lost when the JVM is shut down, so the number should not be too big or you might reach Long.MAX_VALUE too quickly.

The sequence manager allows you to set the range size for each sequence and a default range size value, which is applied to any sequence that does not have a specific range defined. If you want to tune these values, you have to understand the correlation between them.
For example, if you have an average of 20 steps in your process, then it would be reasonable to set the ActivityInstance range size to be 20 times bigger than the ProcessInstance range.

The sequence manager configuration is in bonita-platform-community-custom.properties.

The sequence manager has its own database connection.
This should be appropriately sized for the number of times the sequence manager will query the database, which is a consequence of the range size values. See Database connections.

Bonita Engine has a cache providing a persistence layer using Hibernate caching. It is also known as Second-Level Cache, or L2 Cache.

In Bonita, this L2 Cache is implemented using the Hazelcast library. Hazelcast configuration for this persistence layer is defined in a file named hazelcast.xml.
It is possible to modify the cache settings in this file for each kind of object (Hibernate entity).

Before going into production, we encourage to finely tune the "Level-2" entity cache in a pre-prod environment:

Example of cache configuration, extracted from file hazelcast.xml:

Bonita Engine uses an application cache to store specific objects. The default implementation of this service relies on EhCache. It is configured in these files:

The following cache configurations can be defined:

You can configure the JVM settings for the engine to tune performance.
Check the JVM documentation for details of the available settings.

Notably, we recommend you to set the initial (-Xms) and maximum (-Xmx) heap sizes to the same value.
This reduces the likelihood of the JVM garbage collector starting.
While the garbage collector is running, it prevents creation of new objects, which slows down the application server.

Bonita Engine uses the database heavily, so in consequence a slow database makes the engine slow.

It is essential that the hardware configuration of the server hosting the DB is powerful, considering resources like CPU, memory or others depending on your database instance.

In addition to this, make sure that your database instance is well configured.
Most database softwares provide many options for tuning, and some of them are easy to set up.
Others may be more difficult and present choices between robustness and performance, fast read or fast write, etc.
Your database configuration must be correlated with Bonita Engine usage pattern. To find the right characteristic to optimize, one good starting point is to consider whether you are creating a lot of process instances (in which case optimize database writes) or you are executing a lot of read queries like getTaskList (in which case optimize database reads).
Specific PostgreSQL performance tuning is given as a database tuning reference.

Bonita Engine is natively compatible with the Java Transaction API. This means transaction management relies on a transaction manager.

Bonita Runtime embeds Narayana, an open source transaction manager.

It uses the following configuraton file server/conf/jbossts-properties.xml. The most common configuration to change here would be com.arjuna.ats.arjuna.coordinator.defaultTimeout that is the timeout for transactions. More details on the configuration can be found in the Narayana documentation.

In general, increasing the log level is useful for debugging but has a performance cost.
With this in mind, define the log level for technical logs, queriable logs and archives.

Remember that Bonita Engine dependencies also have their own log and debug options that may impact strongly the system performance.
Be sure to configure these appropriately.

There are several things you can do during the process design to reduce performance overheads.
This is mostly related to reducing usage of extension points when possible.
Consider carefully your usage of connectors, groovy scripts, XML and serializable data.

Events handlers are extensions of the engine configuration.
You can add event handlers for several purposes and you can configure which events you want to catch.
We strongly recommend that you add only appropriate handlers and carefully code the handler filters to handle only those events that you are interested in.

Bonita Engine uses the Scheduler service to trigger timers.

The Bonita Scheduler service implementation uses the Quartz Scheduler. Some quartz properties can be modified to fine tune quartz jobs execution. These properties can be found in bonita-platform-community-custom.properties.

Details on these properties can be found in the Quartz documentation.

They are not read subsequently, so changing the values in bonita-tenant-community-custom.properties after the engine has been started has no effect on Quartz. For value definition, and information about how to update the Quartz trigger tables, see the Quartz documentation about Cron Triggers.

Here is Bonita advice to finely tune PostgreSQL database server performance.

In this example, we assume you have:

Update memory configuration in file postgresql.conf (typically /etc/postgresql/11/main/postgresql.conf) with the following values:

If you want to be able to restore live PITR (Point-in-Time Recovery) backup of the database, ensure archiving is activated:

Update kernel configuration in file 10-postgresql.conf (typically /etc/sysctl.d/10-postgresql.conf; create the file if it does not exist yet) with the following values: