Postman - Performance Issues

Questions
,
#1

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.

#2

Hey @BB9234movwZ4T5c,

Which execution process option are you using? The default own option can be around 3 seconds longer than main, you can find a bit of information about this here: Execution modes and processes - n8n Documentation

#3

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?

#4

Hey @BB9234movwZ4T5c,

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.

> curl -w "@curl-test.txt" -o /deb/null -s "https://automations.mydomain.tld/webhook-test/03522437-87e1-448a-b6e0-8826260e62fb"
     time_namelookup:  0.015718s
        time_connect:  0.022758s
     time_appconnect:  0.041785s
    time_pretransfer:  0.041880s
       time_redirect:  0.000000s
  time_starttransfer:  0.090934s
                     ----------
          time_total:  0.090989s

With Main it is a bit slower but nothing that anyone would really notice.

     time_namelookup:  0.013287s
        time_connect:  0.022034s
     time_appconnect:  0.041096s
    time_pretransfer:  0.041154s
       time_redirect:  0.000000s
  time_starttransfer:  0.099667s
                     ----------
          time_total:  0.099795s

This is of course a test with a workflow that just has a webhook node in it and a curl format file of…

     time_namelookup:  %{time_namelookup}s\n
        time_connect:  %{time_connect}s\n
     time_appconnect:  %{time_appconnect}s\n
    time_pretransfer:  %{time_pretransfer}s\n
       time_redirect:  %{time_redirect}s\n
  time_starttransfer:  %{time_starttransfer}s\n
                     ----------\n
          time_total:  %{time_total}s\n
#5

Thank you, @Jon .

You previously said that the own option can be 3 seconds longer than main. The link that you sent says about one second to spin up. It lists the benefits of main as “minimal latency”.

Based on this, it’s not clear to me why main could be slower.

I am also not sure what the numbers you sent mean. My assumption is that it’s the total time to spin up a process which, in both cases, was below 100 ms which is not ideal but tolerable.

On another note, RE: Execute workflow node missing? - Questions - n8n, would that second workflow also experience a startup delay and, if so, would it be less since the trigger is not a webhook?