In my experience, N8N is not really made for real time stuff. At least not when a small latency is needed.
A workflow itself is quite fast, like you saw in your logs, your workflow did only take about 0.1 second. What takes that long is the time between N8N receiving the data and N8N executing the workflow.
For example, I’ve got following small workflow for my uptime monitoring. The Average time for that workflow for my 1 Server is 1.98 seconds and my second server 3.02 seconds (both are the same version, hosted in docker swarm on a similar Hetzner VPS in the same location.)
Interestingly, my N8N instance only shows 0 Seconds, without milliseconds?
Maybe someone from the N8N Team has some more technical insight on this, would be interesting
Last night, I remembered that n8n spawns a separate threat for each execution, which is probably the ~2-second delay we are seeing here.
N8N can execute executions two ways, in main mode or in own mode. own mode executes each execution in its own thread (which needs to be configured and started each time. main mode executes each execution in the main process.
With a standard N8N installation, own mode is configured.
Exactly @FelixL, the difference in the time it displays and how long it actually takes to run the workflow, is caused by using own mode and the related process spawn time.
As soon as it gets changed to main mode, it should be lightning fast and also use much less memory. So I advice to change it.