Response time high compared to my expectations and node-red

[Micke]

Describe the issue/error/question

Hi,
I am building a small API using n8n and notice that latency is higher then I expected. I have tried webhook instance and also running only one instance in main mode. So I did a simple benchmark using postman 15 times and note min and max response time and with node-red as reference. My test don’t actually fetch any data.

More details regarding response time below but short version:

• Node red is between 2x to 7x faster,
• Adding a second step adds 2x response time, A third step makes little difference. (Realistically an API need more then one step when returning data),
• I have tried MAIN mode.

I really love n8n interface, the promise of scalability with redis queues and a hosted cloud. With high load it might be quicker in comparison have not really tried that yet, but for relatively low loads is there a way to increase the speed to something closer to node-red or for that matter a “native” program?

n8n Queue-mode with Webhook node
1 .N8n: Webhook with “Immediately” 14-30ms. Avg: 19ms
2. N8n: Webhook with “Using ‘Respond to Webhook’ Node” 41-202ms. Avg 50ms

n8n Main-mode

1. N8n: Webhook with “Immediately” 15ms-55ms. Avg: 20ms
2. N8n: Webhook with “Using ‘Respond to Webhook’ Node” 31-48ms. Avg: 38ms

node-red
3. Node-red: Simple HTTP in → Template → HTTP out 6-12ms Avg: 8ms

Information on your n8n setup

• **n8n version:0.202.1
• **Database you’re using (default: SQLite):SQLite and Postgress
• **Running n8n with the execution process [own(default), main]:Both
• **Running n8n via [Docker, npm, n8n.cloud, desktop app]:Docker

[MutedJam]

Hi @Micke, it seems to me you’ve already applied sensible options so I don’t think there is much else you can do in order to speed up things unfortunately. n8n isn’t super performant by design - each node runs independent of each other and will transform the data (often multiple times, for example when parsing the input data and formatting the output data). n8n will also store execution details and sometimes performs actions native code wouldn’t (e.g. opening and closing database connections to the same database when multiple database nodes are used).

In most cases (like all my use cases) these delays are negligible, but seeing this isn’t the case for you I’ve converted your question into a feature request so you and other users can leave a vote on looking at possible performance improvements going forward.