Hi ,
I’m observing some behavior that doesn’t quite add up, and I’m hoping someone can shed some light on it.
Scenario:
I’m running a Flowable Engine 7.2 with a Spring Boot application. The workflow contains a minimal Groovy script that simply appends `“hello world”` to a JSON and returns. I’m also using transient variables with `history = none`.
With 2 instances, each having 8 cores and 8 GB RAM, and a load of 200 users, I see an average latency of around 20 ms. However, when I scale out to 5 instances, each with 3 cores and 3 GB RAM, the latency drops to around 8–9 ms.
In both cases, the PostgreSQL server shows no significant CPU or memory spikes — it stays around 20–30% utilization. The system overall appears to be database-bound.
The change: Scaling the application pods from 2 to 5.
The surprise: Instead of adding overhead, the overall latency actually decreases.
Since the database capacity didn’t change, I initially assumed the bottleneck was purely at the DB layer.
The question:
Could Flowable have internal `synchronized` blocks, thread contention, or other concurrency limitations that cause a single pod to slow down under higher parallel execution load?
Why would distributing the same total workload across more (but smaller) pods result in noticeably lower latency?
No, Flowable doesn’t have a limiting factor here (the async executor is the exception). How are you testing this? Through a REST call? If so, I assume you are hitting the limit of the webserver request handling?
All executions are synchronous workflows invoked through REST and load-tested using JMeter. Each workflow call completes in approximately 6 milliseconds. The inflight request count remains around 50, which is well below the configured thread pool limit of 800.
In Elastic APIM, we observed that some database operations intermittently take up to 50 milliseconds, particularly during reads from the RU execution table and during transaction.commit.
Can there be a database contention change with 2 to 5 pods?
@dhatric when doing the 2 node tests have you configured the Datasource pool?
The out-of-the-box defaults from Hikari (the default connection pool with Spring Boot) is max of 10, which means that if your are testing with 50 parallel requests with 2 nodes there will be a max of 20. I would advise you to adjust the following properties:
We have taken care of database connections too. For each instance we have 200 set for both minimum and maximum pool size and the database supports 3000 max connections.