I find that, when testing my workflow using Postman, the response times are unacceptably high. I regularly see a response time of 8-12 seconds yet n8n shows an execution time of less than 100 ms in some cases and less than 4 seconds in most cases. It seems that the response is 5 or more seconds higher than the actual execution time.
I also find that the response time just to send test data to the webhook is 4-5 seconds.
Is there a delay in triggering the workflow that is not captured in the recorded execution time? I do not see how such a delay could be explained by latency between Postman and my server.
I am running 0.217.1 in Docker and have not yet enabled Queue Mode.
Thank you for the quick reply, @Jon . I am not using the EXECUTIONS_PROCESS environment variable so it is using own. This is confirmed by my stress test hitting 800% CPU utilisation.
I do plan to move to Queue Mode which should reduce latency but how can I best utilise the available CPU cores on the server if each worker will be bound to one core? Do I just match the number of workers to the number of cores?
Sadly if you are using own mode for the process it will be a bit slower for webhooks as documented, I suspect even when using queue mode you may see a similar issue as it takes a bit of time for the OS to fire up the worker…
You could try changing the workers but I don’t think that will impact anything if you are using once instance of n8n. The response does also depend on what the workflow is doing but if it is finishing in less than 100ms then it could be that it is taking longer than normal to create the instance to handle it which could be down to load or something else.
As a test it would be interesting to see what result you get back with main as the execution mode, I know on my local setup I use own and my response is pretty good.