Let me just start with the usual stuff about how much I love working with N8N.
However, recently I have noticed some very significant performance problems in the UI. Some of it has already been discussed in this thread: Aw, Snap! Something went wrong
But the problems are widespread and the new Code node is (for me) almost unusable. The autocomplete feature is probably nice but in the current form it slows the editor down to an almost stand still.
I believe my problems are caused by rather large Input/Outputs (not in the megabyte scale, but large), and this slows the entire UI down. My feeling is that the (brilliant) N8N developers probably work with much smaller datasets and therefore don’t really see the issues.
So I will just encourage N8N to focus on performance - the way is goes right now (almost worse for each release) I fear that I will have to stop using the tool.
First, thanks great to hear that you love working with n8n.
Regarding performance. Did you try the latest version (0.199.0)? That has an issue fixed regarding that. Regarding the code node specifically, is it already on our to-do list to check.
Thanks. I did create a small workflow that slows my UI down (v. 0.198.2) dramatically. I haven’t the new version yet, but will look forward to testing that:
Hi, I have major UI performance issues on version 0.205.0 I was at 0.19xxx before and it was already weak there but now it is unbearable.
On a Quadcore i7, 16GB RAM, with Samsung NVME SSD and Chrome or Firefox browser the UI is consuming 5GB RAM and is so slow that editing workflow or controlling executions is impossible.
Setup is on docker in queue mode, following official docs. Instance with 8Cores and 16GB Ram.
On small test workflows with max 10 nodes it is smooth but beyond that not at all.
Any similar experiences and/or solutions available?
Just a idea what kind of workflows were working before:
fyi as you are running n8n in queue mode, you would have to make sure all n8n instances have exactly the same ./n8n folder (so not just the same content, it has to really write to the same location) else it will no work.
@netroy yeah the N8N_DEFAULT_BINARY_DATA_MODE I missed while updating. After chaning it it is “little” faster but still the UI is almost so slow that working on a big workflow is not really possible.
@jan Thanks for the advise. I setup the swarm all in one docker stack with “x-shared” parameter between all services and it works fine.
The general workflow execution performance increased from normal to queue mode and in general if someone does not need to use the UI much its nice
yes I did that. Recreated the stack. But like mentioned only a very small increase in UI speed.
also I have to pullback my statement that queue-mode was increasing execution performance. Several workflows which were 40 minutes before are not 1:05 hours with 3 workers and 100 concurrency.
