Yes, I patched the MyBatis Query and patched the engine, and compared my adjusted engine with the “normal” one.
I roughly copied your process engine setup:
Every delegate has a logger and a 200ms sleep
I set up a Docker Compose file:
version: "3.2"
services:
postgres:
container_name: camunda_db
hostname: camunda_db
restart: unless-stopped
image: postgres:latest
command: -c 'max_connections=200'
environment:
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=postgres
- POSTGRES_DB=postgres
- POSTGRES_PORT=5432
camunda_nodes:
image: operaton-spring-example:0.0.1-SNAPSHOT
deploy:
replicas: 10
restart: unless-stopped
depends_on:
- postgres
environment:
- SPRING_DATASOURCE_URL=jdbc:postgresql://camunda_db/postgres
- SPRING_DATASOURCE_USERNAME=postgres
- SPRING_DATASOURCE_PASSWORD=postgres
camunda_lead:
image: operaton-spring-example:0.0.1-SNAPSHOT
restart: unless-stopped
ports:
- "8080:8080"
depends_on:
- postgres
environment:
- SPRING_DATASOURCE_URL=jdbc:postgresql://camunda_db/postgres
- SPRING_DATASOURCE_USERNAME=postgres
- SPRING_DATASOURCE_PASSWORD=postgres
And I stole your config:
bpm:
job-execution:
enabled: true
queue-capacity: 10
core-pool-size: 3
max-pool-size: 5
lock-time-in-millis: 300000
wait-time-in-millis: 1000
max-wait: 10000
max-jobs-per-acquisition: 10
I then sent 1000 message events to the camunda_lead.
Processing with the unchanged engine and 10 nodes: 40 seconds
Processing with the unchanged engine and 5 nodes: 35 seconds
Processing with the adapted myBatis Query and 10 nodes: 22 seconds
This is not representative, of course, but I think it is an interesting experiment.
