Stacc Flow performance tuning

The high degree of flexibility in the Stacc Flow platform enables solutions with very different characteristics and requirements. Below is a guide of the different components and infrastructure that may be tuned in order to improve performance.

We recommend doing a performance test before deploying the initial solution in production to ensure the cloud setup is tuned for your solution. It is also recommended to do a performance test before deploying major changes in production.

Cloud (Kubernetes) setup

Below is a recommended setup for a basic production environment. Based on your requirements and performance needs, the numbers may need to be adjusted.

Kubernetes production Pod settings

Service	Number of pods	CPU limit	CPU request	Memory limit	Memory request
Flow-process	2+	1000m	800m	800Mi	750Mi
Camunda	1*	900m	800m	850Mi	800Mi
Flow-portal-web	1+	50m	40m	110Mi	90Mi
Flow-portal-api	1+	110	100	250Mi	230Mi
Services-identity	1+	150m	100m	400Mi	300Mi
Services-decision-evaluator	1+	50m	40m	135Mi	105 Mi
API Gateway	2+	120m	100m	220Mi	200Mi

The actual number of pods depends on the requirements for redundancy and performace requirements in the solution

If the Stacc Flow platform is set up in Azure the default set up is using Azure CosmosDb. Below is recommendation for how to use and set up Azure Cosmos.

Please contact us if you want to deploy the solution in other cloud vendors or managed mongoDb database providers.

Azure Cosmos database performance

Flow Process uses the Azure CosmosDb for storage of Flow instanses. A key concept in the Azure CosmosDb with regards to performance is Request Unit per second for (RU/s).

It is important to find the correct RU/s settings for the production environment in order to avoid slow database operations and rate limiting.

In order to avoid using too many RU/s it is generally recommended to index fields that are queried/sorted and limit the amount of data that is returned using Views.

Here is an article describing how to measure the RU/s for your requests:

https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb/find-request-unit-charge-mongodb

It is recommended to set up auto scaling if the work load is unpredictable or varying.

You can read more about autoscaling in this article https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-choose-offer.

Flow case Manager performance tuning

Queues

It is recommended that all queue definition queries use views / projections to limit the amount of data returned from the Flows. The view can be customized per queue, but often the solutions have a common view across queue definitions.

For each queue it is recommended to limit the number of Flows and define a reasonably polling intervall.

NB!! The task filter functionality is to be used as a special case only. Using task filter can impact the performance severely so use it with caution. Instead of using task filter we recommend using OnCreate/Complete handlers to set/update a field that may be used to indicate that the task is active or not.

Inbox search

This feature enables searches for cases to find out which queue the case is in. It is not recommended to use this a general search functionality as this can impact performance severely.

This feature uses currently a brute force search mechanism and the performance depends on the following:

• The number of queues that is defined
• The number of search fields defined
• If task filters are enabled on queues
• The number of Flows in the database

The search fields are appended to the queues query and the search is executed in parallell.

Search fields

Is it strongly recommended to limit the number of search fields to use. Normally this is either referenceNumber of an external Id set on the Flow.

Flow Process performance tuning

In order to get the best query results, we recommend doing the following.

Flow Process dashboard

The Flow Process dashboard has metrics that may be useful in order to get an overview of potential issues in the solution. The dashboard is available from Flow Process v11 or newer.

State schema

Define a state schema for all processes. The state schema also har functionality to automatically create an index in mongoDb for better performance

Quering

• Including a ?flowDefinitionId= parameter wherever possible when querying flows
• Avoid querying flow state-fields (i.e ?data.foo=bar) if not including a flowDefinitionId parameter

Views

• Create views for reducing the amount of data returned for queries both in Case Manager, API Gateway or other components.

Flow permissions

• If using task or flow-permissions, make sure to include flow-process-userheader with a JSON object that would receive read permission for the objects you are trying to query for. Example (roles and properties may differ based on config)

State

• Limit the amount of data stored on state. Data used for drill down and additional JSON-data should be stored as files or in a different datastore.

Variables

• Avoid large datasets in variables since these are passed/copied between Flow and the process engine itself and may affect the performance.