However, this search takes 35–40 seconds to return results after starting a process instance.
I expected the tasks to be searchable almost instantly (within 1–2 seconds).
Is this delay normal in Camunda 8.8?
Are there any known performance issues or configuration tweaks that could help reduce this delay?
Also, I’d like to know: Would it be better to use the Feign REST API (/v2/user-tasks/search) instead of the SDK’s camundaClient.newUserTaskSearchRequest() for faster results?
Or is the SDK still the recommended and most efficient approach ?
as the Spring Boot starter resp. Camunda client uses the REST API under the hood, I expect that using the API directly or an alternative client would not change a thing.
I gave it a try myself and got a result within 2-3 seconds. For this, I used this code:
@PostMapping("/process-instance")
public UserTask createProcessInstance() {
ProcessInstanceEvent processInstanceEvent =
camundaClient
.newCreateInstanceCommand()
.bpmnProcessId("userTaskProcess")
.latestVersion()
.execute();
return awaitUserTask(processInstanceEvent, "Activity_0nhuyco");
}
private UserTask awaitUserTask(ProcessInstanceEvent processInstanceEvent, String userTaskId) {
SearchResponse<UserTask> execute =
camundaClient
.newUserTaskSearchRequest()
.filter(
f ->
f.processInstanceKey(processInstanceEvent.getProcessInstanceKey())
.elementId(userTaskId))
.execute();
if (execute.items().isEmpty()) {
try {
Thread.sleep(100L);
} catch (InterruptedException e) {
throw new RuntimeException("Interrupted while waiting for user task", e);
}
return awaitUserTask(processInstanceEvent, userTaskId);
}
return execute.items().get(0);
}
Note: The recursion might not be the most elegant approach here, a resilience4j wrapper would be better, but I wanted to make it work quickly
So I believe there could be an issue with:
the exporter
the underlying elasticsearch
Are there any suspicious logs indicating this?
What I also see is that you are adding a sort and page which is not required in that situation. Would it speed up things if you remove them?
I tested your exact code , and unfortunately, I still get a huge delay.
The call to newCreateInstanceCommand() and newUserTaskSearchRequest() takes around 1 min 50 s before returning a result.
Here’s what I see in the logs:
o.s.b.a.health.HealthEndpointSupport : Health contributor io.camunda.client.spring.actuator.CamundaClientHealthIndicator (camundaClient) took 40327ms to respond
So even the health indicator of the camundaClient takes ~40s to respond.
It seems the delay happens before the actual search result — maybe at the client connection or exporter synchronization level?
I had around 20 job workers running in my Spring Boot app (for different task types).
After I commented them out, the start + awaitUserTask execution dropped from ~1m50s to 3s.
In the logs, I noticed this for each worker:
[pool-2-thread-1] io.camunda.client.job.poller : Polling at max 32 jobs for worker createReservationListener#CreateReservation and job type CreateReservationListener
So it looks like all these workers were polling simultaneously and causing load on the Zeebe broker — even though I wasn’t actively using them during the test.
In my real BPMN process, these workers are required since each one handles a specific service task
I’m still experiencing a noticeable delay (sometimes several seconds) between starting a process instance and being able to retrieve the first user task — even after applying all the recommended worker configuration optimizations.
what would definitely help would be to use a user task listener. In that way, you could remove the polling part and rely on the callback from the listener.
Would it be better to use the Feign REST API (
