Slow GUI -- Browser

In the last 4-6 weeks, the GUI has been extremely slow. I think it happened around the time of the update that added grouping. However, that could definitely just be a coincidence. If I delete a couple of nodes, it takes seconds. If I try to delete 10-20 nodes, it could take 20-40 seconds or I might even get a Page Not Responding error. It is even slow when closing a Node Edit page. However, Deploy seems to be running at same speed and all of my automations, mostly based on Hubitat, are running quickly.

I am running Node Red on an RPi4 8GB model with an SSD and using Google Chrome on Windows 10 machines to interface. I have tried on other browsers incl Firefox and still same slowness.

I saw suggestion on another thread to look in the Chrome Console for errors and have this error:
image

I have found a few threads of people with similar error but none of the threads seemed to have a solution. I tried reverting my Node Red install to 1.0.6 but didn't help. I have 1.2.1 installed currently.

Any guidance would be appreciated. Thank you in advance

Recently I notice the dashboard slowing down when I was pushing into swap space. Happen to be running some flows on an older model A Pi, that is already tight on memory, so was abusing it, to be sure. Not seeing errors as yet, but watching for them.

To be clear, you are running the node-red editor on a windows 10 machine?. (The server (RPi) is irrelevant in this case as the editor is purely client side)

Also, to be clear, this slowdown is when you delete nodes from the node-red editor canvas (not when you deploy the changes) right?

I would firstly check your windows 10 machine is not busy (open task manager ctrl+shift+ESC) and check the processor usage before & during this operation)

Question, how many nodes do you have on this tab you are editing? If you have lots, would it be possible to move some parts of your flows to other tabs? That should speed up the editor.

Ps,

The sourcemap warnings in Devtools are not related, they're just letting the developer know they did not include sourcemaps to help debugging. They are not required & their absence have no affect on the operation of the web pages.

2 Likes

Yes, I am running the editor on a Windows 10 machine. I have actually tried a couple of different computers using both Chrome & Firefox browsers.

Yes, this is when I cut & paste nodes or even closing Node Edit dialog is slow. However, deploying seems to be at same speed as always as is installing new palettes.

I have a flow w/ only 7 nodes. I can select all and hit CUT and it takes over 4 seconds for them to disappear and takes a couple of seconds to come back when I PASTE. If I do the same on a tab with multiple sequences and it takes 10+ seconds to CUT. It's not the end of the world, just annoying, & it hasn't always been this slow.

Thanks for the heads up that the errors I posted are not related. Usually, when solving problems like this, it is ruling out what the cause(s) isn't.

Can you stop node red and re-start it in a terminal, and post the output you get here please? Assuming that you used the recommended install script then you can do that using
node-red-stop
node-red-start
When pasting the output use the </> button at the top of the forum edit window.

@stephenn,

I am mostly convinced this is a client side issue not a server side issue

Perhaps there is 1 or more particularly large nodes with LOTS of data in?

For example, if you have encoded a REALLY BIG image as a base64 and saved it in a function/template/inject node? or you are using a template node with MBs of HTML/CSS in?

Out of interest perhaps you could export "all flows" and share them for inspection?

If you feel adventurous - look into using the Performance tab in chrome devtools - you might find a bug

Probably correct, but the startup log might show something useful so worth checking.

Ah, I would beg to differ as a side note, if the server side is bogged down, the UI will expose it. Any query for data/update server side that needs to be send to client side, the UI presents the lag if such happens.

But his operations are not client - to - server operations, only cut + paste nodes (operations that I am fairly certain do not do any client --> server side comms). And to back that statement up - try stopping node-red server, you can still copy and paste and add and delete nodes all day long without any issue (of course you cant deploy until you restart the node-red server).

However, I would agree if there are LOTS of debug comms hitting the browser, that could slow things down.

If the OP pastes his flow we can evaluate this.

The startup from logs is below. After starting, it goes into initializing all of my Hubitat Nodes then waits for things to happen. The initializing of Hubitat nodes only takes 10-12 seconds.

Starting as a systemd service.
18 Oct 10:31:44 - [info]
Welcome to Node-RED
===================
18 Oct 10:31:44 - [info] Node-RED version: v1.2.1
18 Oct 10:31:44 - [info] Node.js  version: v12.19.0
18 Oct 10:31:44 - [info] Linux 5.4.51-v7l+ arm LE
18 Oct 10:31:44 - [info] Loading palette nodes
18 Oct 10:31:50 - [info] +-----------------------------------------------------
18 Oct 10:31:50 - [info] | uibuilder initialised:
18 Oct 10:31:50 - [info] |   root folder: /home/pi/.node-red/uibuilder
18 Oct 10:31:50 - [info] |   version . .: 2.0.8
18 Oct 10:31:50 - [info] |   packages . : vue,bootstrap,bootstrap-vue,jquery,socket.io
18 Oct 10:31:50 - [info] +-----------------------------------------------------
18 Oct 10:31:50 - [info] Dashboard version 2.23.4 started at /ui
18 Oct 10:31:50 - [warn] ------------------------------------------------------
18 Oct 10:31:50 - [warn] [node-red-contrib-speedtest-updated/speedtest] Type already registered
18 Oct 10:31:50 - [warn] ------------------------------------------------------
18 Oct 10:31:50 - [info] Settings file  : /home/pi/.node-red/settings.js
18 Oct 10:31:50 - [info] Context store  : 'default' [module=memory]
18 Oct 10:31:50 - [info] User directory : /home/pi/.node-red
18 Oct 10:31:50 - [warn] Projects disabled : editorTheme.projects.enabled=false
18 Oct 10:31:50 - [info] Flows file     : /home/pi/.node-red/flows_RpiBB.json
18 Oct 10:31:50 - [info] Server now running at http://127.0.0.1:1880/
18 Oct 10:31:50 - [warn]
---------------------------------------------------------------------
Your flow credentials file is encrypted using a system-generated key.
If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.
You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.
---------------------------------------------------------------------
18 Oct 10:31:51 - [info] Starting flows
18 Oct 10:31:51 - [info] [hubitat config:HUBITAT HUB] Starting endpoint for /hubitat/webhook_
18 Oct 10:31:51 - [info] [hubitat config:Hubitat Hub B 176] Starting endpoint for /hubitat/webhook__
18 Oct 10:31:51 - [info] [hubitat config:Hubitat C-7] Starting endpoint for /hubitat/webhook
18 Oct 10:31:51 - [info] [cronplus:Run Backup] createTask - index: 0, static: true, opt: {"topic":"AT115","payload":"","expression":"0 11 0 * * *","name":"AT115","expressionType":"cron","payloadType":"date","solarType":"all","solarEvents":"sunrise,sunset","location":""}
18 Oct 10:31:51 - [info] [cronplus:Run Backup] createTask - index: 0, static: true, opt: {"topic":"AT115","payload":"","type":"date","expression":"0 15 4 * * *","name":"AT115"}
18 Oct 10:31:51 - [info] [cronplus:Run Backup] createTask - index: 0, static: true, opt: {"name":"AT115","topic":"AT115","payloadType":"date","payload":"","expressionType":"cron","expression":"0 16 4 * * *","location":"","offset":"0","solarType":"all","solarEvents":"sunrise,sunset"}
18 Oct 10:31:51 - [info] [cronplus:Run Backup] createTask - index: 0, static: true, opt: {"name":"AT115","topic":"AT115","payloadType":"date","payload":"","expressionType":"cron","expression":"0 17 4 * * *","location":"","offset":"0","solarType":"all","solarEvents":"sunrise,sunset"}
18 Oct 10:31:51 - [info] Started flows
18 Oct 10:31:52 - [info] [mqtt-broker:Pi  -- 192.168.68.132] Connected to broker: mqtt://192.168.68.132:1883
18 Oct 10:31:52 - [info] [hubitat device:ZWave Range Extender] Initialized
18 Oct 10:31:52 - [info] [hubitat device:Living Room] Initialized
18 Oct 10:31:52 - [info] [hubitat device:Hallway] Initialized. switch: on
18 Oct 10:31:52 - [info] [hubitat device:Dining Room] Initialized. switch: on
18 Oct 10:31:52 - [info] [mqtt-broker:a741347d.df1248] Connected to broker: mqtt://test.mosquitto.org:1883
18 Oct 10:31:52 - [info] [mqtt-broker:PI ZERO 192.168.68.146] Connected to broker: mqtt://192.168.68.146:1883
18 Oct 10:31:52 - [info] [hubitat device:Living Room Double-Tapped] Initialized. doubleTapped: 2
18 Oct 10:31:52 - [info] [hubitat device:Living Room] Initialized. switch: on
18 Oct 10:31:52 - [info] [hubitat device:Living Room] Initialized. switch: on
18 Oct 10:31:52 - [info] [hubitat device:Dining Room] Initialized
18 Oct 10:31:52 - [info] [hubitat device:Living Room] Initialized. level: 86
18 Oct 10:31:52 - [info] [hubitat device:Dining Room] Initialized. switch: on
18 Oct 10:31:52 - [info] [alexa-remote-account:Alexa Acct] intialising "Alexa Acct" with the PROXY method and saved data...
18 Oct 10:31:52 - [info] [hubitat mode:Mode Status] Initialized. mode: Home
18 Oct 10:31:52 - [info] [hubitat device:Force Moisture Sensors Dry] Initialized. switch: off
18 Oct 10:31:52 - [info] [hubitat device:Master Gun Closet Safe] Initialized
18 Oct 10:31:52 - [info] [hubitat device:Declans Bedroom Door] Initialized
18 Oct 10:31:52 - [info] [hubitat device:Master Bedroom Sensor -- Ecobee] Initialized. motion: active
18 Oct 10:31:52 - [info] [hubitat device:Kids Bathroom Motion Light Activator] Initialized. switch: on
18 Oct 10:31:52 - [info] [hubitat device:Kids Bathroom Remote Designator] Initialized. switch: on
18 Oct 10:31:52 - [info] [hubitat device:Apple TV Remote] Initialized
18 Oct 10:31:52 - [info] [hubitat device:Kids Bathroom Remote Designator] Initialized. switch: on
18 Oct 10:31:52 - [info] [hubitat device:Kids Bathroom Remote Designator] Initialized. switch: on
18 Oct 10:31:52 - [info] [hubitat device:Declans Bedroom Door] Initialized. contact: open
18 Oct 10:31:52 - [info] [hubitat device:Master Bedroom Sensor -- Ecobee] Initialized. temperature: 75.4
18 Oct 10:31:52 - [info] [hubitat device:Declans Door] Initialized. battery: 81
18 Oct 10:31:52 - [info] [hubitat device:Master Closet Gun Safe] Initialized. battery: 86
18 Oct 10:31:52 - [info] [hubitat device:Apple TV Remote] Initialized. pushed: 7
18 Oct 10:31:52 - [info] [hubitat device:Kitchen] Initialized. switch: on
18 Oct 10:31:52 - [info] [hubitat device:Office] Initialized. switch: on
18 Oct 10:31:52 - [info] [hubitat device:Laundry Room] Initialized. switch: off
18 Oct 10:31:52 - [info] [hubitat device:Kitchen Wyze Camera Plug] Initialized. switch: off
18 Oct 10:31:52 - [info] HarmonyWS open (192.168.68.116)
18 Oct 10:31:52 - [info] [hubitat device:Office] Initialized. switch: on

I ran the Performance Tab Record for 35 seconds while I cut a 6 node sequence and pasted it back and this is what showed up. I am not sure how to translate but it looks like you can clearly see it taking over 6 seconds to cut and another 6 seconds to paste.

@Steve-Mcl,
Yup... no doubt.

Probably not related to your problem, but my philosophy when there is a strange problem and also one or more apparently simple ones, then always fix the simple ones first in case the strange one is a side effect of the simple ones. So fix the problem with the speedtest node first. Possibly you have installed two similar speedtest nodes (my guess would be node-red-contrib-speedtest-updated and node-red-contrib-speedtest, but possibly not).

Yup. Now it's just the updated version. Thanks but no change to problem as you said.

I had a python script that used speed-test cli, that I used to validate the my flow for speed test. Once in a while I would get some really strange results... when the server selected was completely surprising. At very high demand windows for internet access, the automatic server selection can be odd. But I suspect that is due to my remote location. There is a choke point in and out of the valley I live in, that usually has no impact, even when I am doing online gaming... but with COVID 19, a lot more internet streaming, my local ISP warned that things could get bogged down.

If you rename the flows file to something else and then restart node-red it should make a new empty flows file. If you do that and add a few nodes is it still slow?
Probably a good idea to make sure your flows file backup is up to date first, in case you get confused when messing about with the files and accidentally delete the wrong one.

Also if you set the debug pane to show all debug messages are you seeing messages coming in at a great rate? That is when using the real flows file of course.

Is your browser slow doing ANYTHING else? There is a known issue with browsers and Microsoft Search indexing. I had at one point to completely turn off indexing, and that bypassed the browser performance issue for me. Microsoft is aware of the issue, that browsers can trigger a background index update for Microsoft Search, especially Windows 10 users keep reporting this to Microsoft, but thus far Microsoft has not acted on the issue... the brand new Microsoft Edge... triggered the same issue when I tested for it recently.

I changed flow's file name then added about 25 nodes to new flow w/ no connections to each other and they cut instantly. Nothing unusual is showing up in the debug pane. It seems to mirror what I am seeing in the terminal when I run node-red-log. Is there a more detailed logging option for Node Red?

I haven't noticed my browser slow at anything else.

I also systematically went thru and disabled all but one flow and tested each flow as the only one enabled. I still had same problem.

When I hit the Ctrl-X, it seems that a script(s) is(are) running for up to 50 seconds depending on the number of nodes that I cut. Is there a way that I can see what script(s) it is(are) running from the Performance tab?

Found something interesting... I just pulled my speedtest node flow, that I wrote some time ago, and was working fine at the time. Now, it is reporting very wrong download and upload throughput. For example, on my Pi device, using speedtest-cli with all defaults, my ISP is about 80 Mbit down and 12 Mbit up, but the node reports 10 and 2. And the results are consistently off the mark, sometimes the reported results by the node are a bit better, but nowhere near what the CLI is reporting.

Even running the CLI via exec node, the results to the straight CLI are close and reasonable. It is the node that is grossly out of performance range, CLI or execute node at 80 and 12, the best the node as reported is 30 and 8. Which is a bit odd, but I have yet to look at the source to see if I can spot a reason why.

If I test on different devices and even my router or firewall, the results are very close to the CLI. I posted a question on github to the author of the node, but the node does not appear to be actively supported.

Just for reference...

"491"	"27.512"	"8.468"
"492"	"84.6711"	"11.5492"
"493"	"23.751"	"9.787"
"494"	"86.8558"	"11.9529"
"495"	"32.91"		"9.7"	
"496"	"82.397"	"11.919"

The 400s are just the data base table index, can be ignored, the download MBit/s and upload MBit/s results respectively follow the index #. As you can see the node reported download speed is very different from the CLI reported download speed. I confirmed that the same location and server are used in each test. So the difference in DL speeds is odd, even the UL speeds are consistently different but at least a bit closer.