Hiho my friends,
my homebrew stuff (node red flows) grows on and on. The problem: if my me or my girl friend opens the ui it takes up to 10 seconds to load. - That s not very sufficient if you just want to switch a light on.
So I am searching for ways to boost this. Currently I am using a Raspberry Pi 4 / 4GB.
In my case I ve many flows doing the same stuff but can hard be put together so over the years I always made copies of them e.g. the "switch flow" and then I changed the stuff that s needed to make it individual. - I do not see much optimizations potential to rip parts of them together. but I am not sure how you guys work or it this is the common way. or if this is even the reason for the "slow loading problem". - Is there a way see whats going on while loading the ui ? Would you guess switching from SD-Card to a faster periphery (SSD or so) potentially change anything.
Do you mean the editor UI or are you using the dashboard nodes, or something else, for the operator interface?
Also are you accessing the dashboard from another computer? A phone? By VNCing to the pi?
Also check whether the Pi is using SWAP space. If it is, this will be very slow with an SD-Card.
Generally, even with a Pi 4, best not to run the Linux desktop at all. nor VNC.
Not to forget, check that you do not feed dashboard charts with many datapoints
I mean the dashboard. It is running smooth but the "initial call" first visit of the dashboard takes 10+ seconds if I visit the dashboard by mobile phone. on a fast PC it takes about 5-6 seconds (different browsers does not matter so much).
I tried two different mobile phones and two different desktop PC with different browsers. Not at the same time of course. The result is: PCs 5-6 seconds / mobile phones 10-12 seconds. After this the responsibility of clicking through the dashboard menu is ok (not to slow but not fast). The problem is, if you visit the dashboard you will 99% reload the site and not having an running instance opened. So my girlfriend will run into that problem always.
I checked with "free" and saw that swap was used. I cleared it and disabled it fully but that did not seem to change the long loading times.
since I don t (re)store charts I don t have these problems on "node-red-start". A fresh restart does not boost loading time.
You should not disable swap. There is nothing wrong with using swap provided it is only a small amount, as it can improve the overall performance of the pi. If, however, a large amount is in use then that indicates that you are running out of memory.
The dashboard is fairly intensive in bandwidth and processor usage in the browser during initial opening. It is a single page app so it is all downloaded when it is opened. That is why you can see a significant difference in startup between PC and phone, especially if the phone is not of a high spec. The figures you quote are similar to those that I see.
That is the penalty you pay for using a fairly sophisticated interface that is very easy to configure.
If you need a higher performance then one option is to use uibuilder. It is more complex to setup and needs greater knowledge of html and css, for example. But using it can allow you to optimise the performance in whatever way you require.
Does your pi's power supply is good enough?
When you get a low voltage warming (under voltage) the cpu clock will be throttled down significant.
On a pi 4 you can see at from the red led if the power is good enough. The red led should light constant, if not a brown out (low voltage) is detected.
If you are using nodered-dashboard or similar... basically it does that. Even worse on a cell phone. Horrible, horrible performance.
Try using html template nodes to make your interface and see how fast they perform. It's not the Pi4 because I use a Pi Zero for some stuff and get decent performance.
Dashboard was a nice idea but something hasn't been right with it for a long time.
Thx for your reply @everyone !
@edje11 Damit you are right. I got the voltage warning message but ignored it because I ve red that its a problem of the first pi generation. I swapped the power supply and now it seems tu react much faster! Thx guys this community is rly great!!
What load times are you now getting on the PC and phone now?
@Colin its now up in about 3 seconds on PC and in 6-7 seconds up on mobile phone.
One thing you could do is throw hardware at the problem. The 4B allows a fair amount of overclocking. I have mine running a very conservative 1.8Ghz on the CPU and 600Mhz on the GPU. If you use a newer Bios It's possible to see > 2.1Ghz on the CPU and > 700 on the GPU. (I have the newer BIOS but still overclock a bit on the conservative side).
Here is a guide for overclocking the 4B (a very unlikely source, but Toms has a few contributing writers that like playing around with the Pi).
Overlclocking the RPi4B CPU and GPU
I see others mentioned the powersupply issue.. Glad you swapped that out.
Sorry Colin, even a small amount of use on a Pi with default config will slow things down since memory has to be written to the sd-card and then recovered in the same way. AFAIK, the reason for not disabling altogether is to stop some apps crashing if swap isn't present at all.
Having said that, you can get a one-off or occasional use that will have marked it as used and you may not notice anything. Regular swap events are a major issue though as you say and indeed indicate that you need to free up memory elsewhere.
The smem tool is useful if you think you may have swap issues.
uibuilder lets you build dynamic, data-driven web ui's with minimal overheads but plenty of help. At its simplest, it gives you some front-end code helpers via its front-end library along with a websocket data channel.
OT, I guess it depends on ones definition of slow. I have been running a React dev framework on a Pi 4-2. I ended up setting an 8Gb swap file to eliminate the Pi from literally stopping when it ran out of memory. Performance while not wonderful, was acceptable for small projects.
Don't be scared of using some swap. Try it first before dismissing it outright.
Not necessarily. Even on systems with a reasonable amount of headroom the OS can move rarely (or never) used sections of RAM out to the swap area without impacting performance. That provides additional RAM that can then be used for caching and IO buffers, which can increase the system speed. At least that is what I have been led to believe, see this for example Linux Performance: Almost Always Add Swap Space
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
