I have a simple Node-RED program that is monitoring various sensors (10-12) via modbus, as well as a few buttons for user interaction. The program works great if I use a PC or laptop to access the dashboard via a browser. But when I try to use it directly from the Raspberry Pi 4 (4GB), it is slow and has more lag than I would like and in some cases is unusable. I have three charts but they are set to only show the last 1 hour of data and I only poll the sensors every 5 minutes so I don't believe it is an issue of the chart bogging down the page since I notice the lag immediately rather than after a certain amount of time, and the dashboard is great when accessed from another device.
In researching this topic I have seen mixed results. Some say even the Pi 4 just isn't equipped to display pages with a decent amount of JavaScript content, while others say they are able to run the dashboard fine and it works well but don't give much detail.
The main point of my post is to ask if others have been able to get a responsive dashboard without accessing from another device. Perhaps using something other than a browser is the right way to go, if that's even possible? I have tried different browsers (Chromium, Firefox, Midori, Epiphany, and couple of others), and Midori is the best of the bunch as I can actually view the dashboard without crashing. However some of the dashboard objects don't display. For example the "month picker" object won't accept input and the "calendar" icon is missing. This only is the case in Midori. But Chromium and Firefox are unresponsive and end up crashing after several minutes of attempting to display the dashboard.
Here are some more details about my setup which I hope will prove helpful.
Raspberry Pi 4 (4GB) running 64-bit RPI OS
128 GB class 10 SD card
No overclocking, no RAM adjustments, default browsers with no settings changed.
I have a RasPi3B+ and have used it to do web surfing and display NR dashboards and it works fine.
When running the browser on the Pi, open a terminal and run (after installing) htop.
(Better version of top)
and see if anything stands out there to hogging resources.
(maybe do it BEFORE the browser too!)
Sorry I can't be of more help.
Oh, lastly:
WHICH O/S... Buster, Bullseye, the next one?
I should have mentioned both of the things you specified. 64-bit Bullseye is the OS version, freshly updated.
I used htop and the CPU usage and RAM are low/normal when just running the node-RED program. When I launch a browser I get varying levels of CPU spiking with Chromium and Firefox being the biggest offenders. CPU when opening the browser usually jumps to 80% to 90% or so. Then once I type in the URL and the page starts loading it maxes out. When the page finally loads, CPU drops to around 10% but the page is still unresponsive. I should note this is the same for most webpages that have some JavaScript content, not just Node-RED dashboards. Midori is once again the best with a max of around 40% CPU. The pages are usable, but very slow to update and don't display some content correctly. When I do a tab or group change, the CPU jumps up to 40% again before settling down.
I have used Pi 3's and Pi 4's in the past to do light web browsing and even displayed simple node-RED dashboards and I don't remember having issues like this. For the past two years or so, I have been using Node-RED almost exclusively as headless servers and haven't needed to use the Pi itself to display the dashboard. The only relevant changes I can think of is back then I was using Buster, and a 32-bit Buster at that. I thought if anything I would see an improvement when I started using the 64-bit version.
I have several Pi3B+ and Pi4 running and have no issues regarding lagging on the dashboards. I don't do any charts so I don't know what impact that will have but all mine have several dozen sensors inputting things. When I moved from 32 bit to 64 bit the response did improve noticeably on both models. There are about a dozen pages on each dashboard.
Have you looked at Flow browser?
I have never used it, my Pies have command line OS only and I access them from a PC, but it is said to be optimised for the Pi.
Have you tested your SD card speed with Agnostics?
I run my little Pies on SD cards, but the Pi4 has an SSD and it is much faster, no idea if that would show up in browser performance
Pi 4, Crucial BX500 SATA SSD, Ugreen USB3 adapter with Asmedia chip:
Sequential write speed 315076 KB/sec
Random write speed 18285 IOPS
Random read speed 16157 IOPS
Sandisk Ultra SD card in Pi 4
Sequential write speed 32998 KB/sec
Random write speed 776 IOPS
Random read speed 3307 IOPS
I would be inclined to get a spare Sandisk 32GB micro SD (ÂŁ6 on Amazon I think) so I could compare the performance with Buster, Bullseye and Bookworm 64 bit.
I'm glad that others are having the opposite experience I am, which tells me something is wrong with my setup.
@Trying_to_learn With NR running I launched Chromium and after 3+ minutes I was able to type in a web address, I used "espn.com" as a test and once I hit enter the entire Pi froze and after about another 3 minutes Chromium showed as unresponsive and I got the prompt to kill the process. I then stopped NR, rebooted, and attempted to go to espn.com again. Chromium loaded in about 45 seconds when launched, then it took 3-4 minutes after typing in the address for the espn page to load. It did load this time, but was very unresponsive.
I did a update and full-upgrade yesterday, and today I tried sudo apt install chromium-browser and it responded that I have the latest version 120.0.6099.102.
@jbudd I have read about the SSD improving performance across the board. Unfortunately we have already bought several Pi 4 kits with SD cards and this is what we are stuck with at the moment. I will look into Flow browser!
A 4GB Pi 4 really should behave better with that, even with a desktop loaded. See if you can open the browser's dev tools and look for some errors.
Also check check for large amount of paging (AKA swapping) - this really kills the performance of anything running from an SD-Card. If it is doing a lot, you will need to find out what is hogging the memory.
Oh, and see if you can try with a different make of SD-Card - there are some appalling fakes around. Basically get a reputable make (I always use Samsung Evo or Evo Pro cards from a reputable source). The Evo's have wear levelling which make a big difference to card lifespan.
Finally, recognise that Dashboard 1 is a real hog. A lot of data has to be transferred and a lot of libraries loaded, it will always be fairly slow. Switch to a more efficient dashboard if you need better performance.
Definitely test the SD card performance because there is a very good chance the agnostics test will say "FAIL" for random write speed and then you have ammunition to go back to the supplier and demand better quality.
Mind you, I find these Pi kits very dubious. Funny how when the Pies were like gold dust it was the kits that were in stock. A sign that they have a bad reputation (or other non-positive attribute)?
@jbudd That is probably a good point. I have almost always bought a version of a Canakit whether it was directly from Canakit or on Amazon/Digikey. The Pi4 kits come with 128 GB Samsung EVO Plus cards. I have always been happy with them and they have been reliable for me so far. The oldest Pi I have is a Pi 3 B+ I bought 7 years ago and it is still running happily (knock on wood).
That being said, I have had very little reason to use the browser on the Pi in my time with them. I had a project using Selenium a while back that opened a page, grabbed some data, then closed the page. And that ran very well. It was on another Canakit Pi 4 setup.
I also have a 3B+ using a PNY 32GB card. It has similar performance issues when using the browser. (Also running 64-bit Bullseye).
I think I have a couple of other SD cards I could try for testing purposes, but I know in the past I have had decent browser performance (especially with the NR Dashboard) on the same kits. I believe the only differences were the OS (32-bit Buster and Bullseye vs 64-bit Bullseye). But that seems odd also since others have already reported a positive change when moving from 32-bit to 64-bit.
@TotallyInformation I have been keeping up the the Dashboard 1 "life support" status and I've looked into a couple of other options but none seemed to be quite as "ready" or easy to get up and running as Dashboard 1. Perhaps I've just gotten too "set in my ways" and enjoy the tricks I've learned over the years concerning Dashboard 1. I've looked the most into the Dashboard 2 project from FlowFuse, is there an alternative you would recommend that might get better performance?
I have the same spec 4MB Pi4 and a fairly complex dashboard.
The performance isn't great but usable at a push, and not as bad as you describe, certainly the browser doesn't crash.
Reading your post, it sounds like this is unlike the performance you have seen yourself with your other devices.
So it does sound like something peculiar to that particular setup, perhaps more at the OS level,
Does your dashboard load up any external content etc?
Perhaps you could try using another pi to browse to the dashboard, for comparison ?
If you are just using the rPi to display a dashboard in a browser and not doing any node-red processing (running flows, etc) then use a dedicated kiosk OS.
There have been some great ideas and I appreciate all the replies. I'm going to look into the swap and cache issues mentioned next.
I had a spare 3B+ with a PNY 32GB SD card that I had setup last year around October. It hasn't been updated since then either I believe. I decided to try it just for giggles and it is giving me performance similar to what I remember in the past. The Dashboard/browser performance is not bad, but not great. In addition to looking into the things I mentioned above, I'm also going to use this Pi as a comparison to look at versions of software, OS, etc.
And just to clarify, I am needing to display the dashboard from the same Pi that is running Node-RED.
If the Pi4 has a $hit load of memory, would the cache really be needed/used?
Not against what you said, but this brings to mind something about the cache speed and when using SD cards.
SD cards - despite their speed aren't designed for this sort of stuff and can cause problems.
Can you move the cache to a different device?
Because if you can, try a PROPER USB-3 USB * stick plugged in to a USB port and cache on it.
USB sticks are more designed for this sort of thing/stuff and would/could/should work better.
I remember this from when I had a Pi2 and was having problems with free memory.
The cache was taking up too much memory and the machine would die.
So I got rid of the cache and......
I digress.
But the SD card speeds and how it is used if the cache is on it.....
I remembered that from stuff I read while down that rabbit hole.
Hope that somewhat helps.
And good luck.
There are a lot of USB sticks that CLAIM to be USB-3 and are NOT. So double check their specs and run a speed test before committing to one.
