hi there, I am gaining my first experiences with Node Red with a deployment on a Raspberry Pi 3B.
My test flows work fine when accessing the dashboard / gui from other stations (e.g. Laptop with Chrome browser).
For (emergency) remote access however, I also have VNC running on that Raspberry Pi. This is to access and control not only the "local" Node Red installation but also my home automation controller located in the same network.
When I access the UI for the homematic (RaspberryMatic) device, all seems ok. After a short CPU peak to about 10%, it returns to "doing nothing" ~ 2-3% load.
However, when I access the local Node Red Dashboard / UI, the cpu load climbs very quickly to a steady 60+ % load and stays at that level for as long as I was monitoring it. On that pi I am currently using the default installed Chromium browser. As mentioned before, when accessing that pi from a remote networked computer, the CPU load is basically NOT impacted.
I now also tried accessing the Node-Red instance on the homematic raspberry pi (RaspberryMatic with RedMatic to be precise) and similar, the CPU load goes to about 33% and stays there. So, not as bad as visualising the local instance but still considerable load!
So, that leads me to my question - how can this be fixed?
Will a different browser work "better"? Is there an issue with showing the dashboard / UI on a local node? Can the "load" be influenced by controlling refresh rates or similar (if so how / where)?
Sorry, I have to admit I haven't! As I ended up with Node Red on the Homematic RaspberryMatic, the stand-alone installation was an "afterthought" (and was actually easier then the Homematic RedMatic deployment).
I will probably have to do so!
I presume there is a reference to browser issue or you wouldn't have brought it up!
Thanks for the suggestion!
Actually, I just had a look and what I found, I have read as I had issues with the auto start in my first deployment on a Raspberry Pi that was simulated (!) on VMWare. Got it to work but it took a bit longer then the installation now on my physical device! https://nodered.org/docs/getting-started/raspberrypi
When I look back it states:
We recommend Chromium or Firefox-ESR on the Pi and not Epiphany
So, my issue is with Chromium for the UI end (I am not planning to do development in the Rpi browser).
And as indicated, my initial experience with Midori is about half the CPU load as with Chromium.
Before switching browsers, I would take a look at the utilisation stats of the device.
High CPU can be a result of excessive paging of resources. Something that happens when the OS runs short of memory. I would very much expect that you will see that happening on your configuration.
If you can afford it, go for a second Pi and only run the desktop on that, Node-RED on the original. You can also ditch the default desktop and go for something lighter weight.
If access is for emergencies only, the other thing you can do is set the Pi to default to boot only to the command line (e.g. no desktop) but know how to start and stop the desktop if needed. You can still SSH into the Pi and start the desktop remotely.
Thanks everyone. Just to clarify, I have no performance issues with the Pi when I run it headless! Access to the dashboard from other network devices (laptop, mobile, etc.) do not cause any high CPU load issues.
ONLY when using Chromium (or Midori) on that Pi to access the local node red dashboard, the CPU load jumps from about 2% to 60% (resp. 30% with Midori).
So, I don't fully understand why remote access to the dashboard doesn't cause any obvious load increase while showing the UI on a local browser causes havoc.
Do you by chance run charts or other ui parts on the dashboard with frequent updates requiring redrawing of (part of) the page? That kind of load is happening on the computer that runs the browser. When you do that on a remote machine the source machine has no issues with it. If it runs from the same machine it has to do both tasks.
If you need more than Dashboard can realistically deal with (especially given the limited resources on a Pi), you should consider a more targeted dashboard - probably not using the Dashboard which is very large indeed - or use something like an InfluxDB/Grafana combination to produce your dashboard.
