Running multiple instances for scaling is generally referred to as "horizontal scaling" though more commonly done across multiple devices. It isn't necessarily a bad option and has some potential security and managability benefits too. BUT, Node-RED is not a lightweight app and you would be duplicating quite a lot of stuff you don't really need to.
Not sure if I mentioned in this thread or another - but another option is to use Node-RED for prototyping and non-performance critical things but move things that are causing performance issues into a standard node.js app - that requires additional coding of course, but it removes a lot of node-red overhead.
Similarly, moving some processing from general nodes into a specialist node can also bring some significant performance benefits.
Hopefully you are minimising things like JSONata and combining Function nodes where feasible. JSONata in particular has a significant overhead.
Not only about the CPU performance but also about the whole balance of the device. It will be much better balanced between CPU, memory, disk read/write and network read/write than a Pi. Though of course, a Pi4 is a very different beast to a Pi3.
Yup as long as it isn't memory or network constrained.
Not convinced is it more power efficient than any other computer of comparable power. Also, you need to consider WHICH version you get. I have an older Synolgy and long ago stopped running anything other than file and backup/sync on it even with extended memory since handling 3-4TB of data was challenging enough for it. And, to make matters worse, it does not have a full shell or standard Linux system so unless someone has packaged something for it or you go to the trouble and overheads of running Docker, some things are actually quite hard to manage.
Just out of curiosity, what is it you're trying to do with NR on your Pi that is so resource intensive? I've read through the forum so far (and probably missed it being spelled out in plain letters), but I don't see what you're trying to do. There are means you can use to make NR multi-thread capable, but it somewhat depends on your application. So before I open a can of worms spelling out different methods that aren't needed or don't apply, what is it you're doing?
Over the years the number of my IoT devices has grown and things slow down in general.
Now I added some cams using rtsp streams to view (not possible by iFrame) which has another impact on the load / performance when opening the dashboard. The worst thing is the case when I am watching the cameras on PC and another person is trying to open the dashboard too e.g. for switching the lights. Then it takes more the 10 seconds to open up and in this case the connection gets lost caused by the Raspberry where Node Red runs on. Its not fun especially for family members
I ve tried much to improve the situation (improved flows, disabled chars, disabled Node Red desktop, overclocked Pi, do not move big date by flows.... etc.) but now tips went over to things like running two NR instances, rewrite things in node.js. That s not a way I want to go. I think its a bit on the devs to implement a bit of multithreading or so :). NR is a single page application and JavaScript is single threaded I thing this is the bottle neck in my case (maybe the network connection too, since I am running everything on WLAN). To improve I will add a lot more single thread power and ordered a mini PC which has 4 times more benchmark points than Raspberry Pi 4 and see if it helps
Harking back to one of your other threads, I can pretty much guarantee that ffmpeg + streaming camera images + desktop env + VNC + hitting virtual memory == the problems you see.
There are things you can do to improve matters on the PI but there are limits - I suspect you are there.
With nodejs being single threaded and the PI4 having 4 cores, you could set processor affinity and run 4 instances on different cores (or move single threaded apps to lesser used cores). NOTE: single threaded "sounds bad" but nodejs event queue is proven to excel at things it was designed for - just dont block it (like excessive while and for loops).
You could also feasibly keep the PI for node-red and run processor intensive stuff on the beefier box.
It depends.
Is the bottleneck due to all 4 CPU cores being very busy or is the bottleneck due to node-red (node.js) using all CPU power of one the 4 CPU cores ?
CPU monitoring can immediately make clear in which of the 2 situations you are.
I am suspecting that node-red is the bottleneck for you.
If node-red is the bottleneck then I would spend some time identifying the actual node(s) that take a long time to execute. You can look at the debug output, disable flows, temporary unwire nodes to figure this out. The nodes related to ffmpeg processing and streaming of your camera data are the primary suspects.
There are other assumptions (I did not spell out) for example, the use of VNC implies using a browser on the PI. With the amount of (useful) stuff the OP has going on in their dashboard (see other thread) I would not be the least surprised things are slow.
And if virtual memory is being touched - all bets are off anyway.
accessing the swap file is a significantly slower process that can create slowdowns
It sounds like there is a lot of room for improvement still, but not in the way you've been looking. I can think of a couple instances that may help. Though I don't know your setup and everything you're trying to do, I can guess at a few things that could help.
Everyone assumes that Javascript is a single-threaded application. The core of Javascript is. However a feature was introduced over a decade ago that actually made multi-threading possible. It's called Web Workers and is an implementation that allows you to push a separate script to a different thread for processing, and thus possibly utilize a different core of a multi-core setup. Javascript handles the communication between the core script and the worker quite nicely and makes possible the ability to do crunching on a different thread while the core thread handles user interactions.
Another underutilized method of speeding up Node-Red is to push processing of something from the server to the client. A properly load balanced server will process the things that need to be processed once (i.e. a video uploaded to YouTube), and then serve the data that the clients need the rest of the time. I'll give a real-life situation. I have several tables that are dynamically updated on a couple web pages along with graphs and stuff to monitor things. The original implementation of the table ui had the table rendering on the server and then pushing the rendering to the client to rerender graphically. It was extremely inefficient and caused a lot of load that was unnecessary. Now I use Tabulator directly (the module that the table ui is built on). The server sends the script to the client where the client renders the table and pulls the data from the server. All the server does is send the initial script and then send the data when it's polled. The client does all the rendering. I still have the load of the charts and whatnot on the server because I haven't figured out a way to render them on the client side. This idea doesn't specifically apply to your case (or does it?), but the concept behind it should.
This kinda relates to the previous suggestion. Have multiple servers serve a client. Not only does it load balance a single server, but it load balances all possible data that could be going to the client. You're processing RTSP streams, which suggests you have IP cameras you're monitoring. Instead of having the server either render or forward the RTSP streams to the client, have the client connect to the camera itself to pull the RTSP streams. Several apps are built on this concept to make multi-camera environments work over IP. If Node-Red can access the RTSP streams, Javascript can too and all you need to do is put the script onto the client and point to the stream (may need to be done through ui-template). This will unburden your server for the RTSP stream and open resources for other stuff.
Again, I don't know the specifics of your implementation, but these suggestions should help most users out there. I can't tell you how to optimize your setup, but if you work with these concepts, you should be able to spread out your workload to other threads and even other systems. Hopefully that helps.
I agree. Thanx guys for all inspirations and comments.
I think there are ways but no way is easy and most are very time consuming and needs skills that I dont own. (For example letting RTSP streams decode by clients... I tried to implement a web player one year ago but failed). Node Red is an easy and fast way to get results that s why I use and like it. For me it should stay that way. Not everyone has the skills or the time to dive deep into senior coders solutions. I am convinced that Node Red should somehow get better multi-threading support by the devs.
But again: Thanx for your great support and thinking about problems of a foreign guy of the internet instead of doing something you more enjoy.
as long as it isn't memory or network constrained.
