Performance

This page explains specific performance-related topics of database queries. It does not attempt to provide tools and guidance for general performance analysis and optimization of CIB seven installations.

As the impact of the settings discussed here largely depends on the setup and workload of CIB seven, the recommendations may or may not help in your case. Performance improvements are not guaranteed.

Task Query

The task query is one of the heaviest used and most powerful queries of the process engine API. Due to its rich feature set, it can also become complex in SQL and may perform badly.

Disabling CMMN and Standalone Tasks

To perform transparent access checks, the task query joins the authorization table (ACT_RU_AUTHORIZATION). For any kind of process-related filters, it joins the process definition table (ACT_RE_PROCDEF). By default, the query uses a left join for these operations. If CMMN and standalone tasks (tasks that are neither related to a BPMN process, nor a CMMN case) are not used, the engine configuration flags cmmnEnabled and standaloneTasksEnabled can be set to false. Then, the left joins are replaced by inner joins which perform better on some databases. See the configuration properties reference for details on these settings.

Identity Provider

Every query that performs a transparent authorization check joins the authorization table (ACT_RU_AUTHORIZATION). The groups of the authenticated user are passed into that check as an IN list over GROUP_ID_, with one entry per group. The more groups a user belongs to, the larger that list becomes – on every authorization-checked query, for every user.

It is therefore worth checking what your identity provider actually returns. If it exposes every group of the underlying user directory, users may carry hundreds of memberships that are irrelevant for CIB seven, and each one widens the IN list. Restricting the provider to the groups that are really used for authorization keeps the check small.

With an external identity provider (LDAP, OAuth2, SCIM2), users and groups are not read from the process engine database at all, but fetched from the third-party server on every lookup. Response times then also depend on how fast that server answers – a slow directory shows up as slow requests even while the database itself is idle.

For the LDAP plugin, both aspects – narrowing the user and group search, and the optional query cache – are described in Performance of the LDAP Plugin.