so im runninjg node red on raspberry pi 3+b and have around 400 nodes the program is lagging more and more is the a easy fix or way to run better
thanks in andvance
Ivar
Can you define what you mean by lagging?
Are you using dashboard charts? If so what time span is it/they configured for, how many lines are there and at what rate are you sending data?
If the lagging effect is to do with the user interface are you running the browser on pi or on another machine connected to the pi?
no im not using charts just a lot of nodes on 1 page running and by lag i mean the program slowing down when moving nodes and deploying flows, just slowing down in general.
Sounds like you are reaching the limitations of your pi.
You mean the editor is slowing down, rather than the runtime performance of the flows themselves?
Can you describe how you have your flows organised? All on one tab? Multiple tabs? More details you can share, the more we can understand what could be causing this.
yes i mean the editor slowing down,
I have everything in 1 flow around 400 nodes but those nodes spread over 3 dashboard tabs
the code works but fine but the editor is slow to deal with
So the immediate fix would be to split them over multiple tabs so the editor has less work to do when refreshing the view.
Would be interesting to know, what task the 400 nodes are for...?
Are you doing a full deploy each time?
Doing a Modified Flow, or Modified Node deploy is much quicker.
I have 8 dashboard buttons that when pressed to trough one of these things
to simulate a car going past a barrier to test the barrier
with 8 different senarios
@knolleary thanks that helped
@Paul-Reed that also helped thanks forgot that existed
Though it sounds like it is your browser that is slowing down, still check out how hard the Pi is working as well. One quick fix is usually to turn off the desktop on the Pi if you don't really need it. That frees up loads of resources and may speed things up for you.
I don't think you answered the question, are you running the browser on the Pi? If so then, assuming you have a PC then don't. Run the browser on your PC using the IP of the Pi in the browser URL. Even better if you disable the GUI in the pi completely.
One thing that hits me every time is large data in messages -> browser - i.e. debug nodes.
Also watch out for Clone on multiple wires from a node if msg is large - that can kill performance.
Also, if > 0.17, watch out for data in context, flow, and global. This data is also sent to browser (killed me with putting BLE data in global, found data to be very deep and recursive, and completely killed my pi with PC running the browser).
A 'solution' to large data in global/flow/context is to put a function in global/flow/context which when called returns a reference to the data - so ensuring the data itself does not go to browser.
Very bold statement but I think leads to wrong assumptions like using context memory is something that the one should avoid. Shouldn't it say that moving data over to the frontend (dashboard) should be done by filtering out only necessary data to be sent?
bold but true.
Try putting a huge structure in flow.set and see what happens!
Yes, putting large structures in context, flow, or global should be avoided like the plague; even if using <= 0.17, because you will upgrade at some point.
NR was not designed to have huge structures in these areas....
s
I should add to that second bold statement that context, flow, and global are VERY useful, so please use them - but just be aware of what you are putting in them with later versions of NR.
I can't upgrade my production versions until I rework close to 200 flows :(, it came as a shock what my flows did to the GUI performance when I upgraded - I did not mean to be negative!
s
1 Like
This part of the discussion has gone right over my head, but I think I should try to understand. Could someone please explain precisely what causes the problem? Is it the runtime, editor, or a browser that is slowing down? If a browser, is it connected to the editor or dashboard? How does @btsimonh's approach solve the problem?
Have you fed this back to us before? Apologies if you have, but it's the sort of feedback we need to hear so we can learn from it. Hearing you can't upgrade due to these changes is disappointing.
Just to correct one point... we only load a node's context of you click the refresh button. Global context is only loaded once, unless you click it's refresh button. Flow context is automatically refreshed when you change tabs.
From your feedback, it sounds like we should have a toggle switch to enable this behaviour.
1 Like
hi Nick :).
So, I've stirred again!
no, i don't think i fed it back at the time; when I found the issue, I just thought 'oh dear, you are being very stupid'. I put a reference to noble BLE devices in global, and when i looked at the depth of the object, it really was VERY extreme; but the fact it killed me scared me.
One good solution inside NR would be to duplicate any item it's going to send to the browser (and ONLY if the browser is connected), but limit the depth to (n). This would then mean you could not kill yourself with data.
I've got a number of flows which can have extreme objects in things now exposed to browser (both messages and flow/global); I try to avoid this now, and am mindful of the possible issues.
But browser bandwidth/processing in NR related to UI tasks is something which is important to understand when building flows. I kind of abuse everything, but I thought it was an important possibility to highlight in this thread; poor performance can come from a number of less-understood sources.
(recently, even though I kind of have a handle on this, and audio processing flow was taking over a second to do something simple. Removing one debug node, a double wire from one node, took the time down to 100ms, a 10x performance improvement from one apparently inconsequential rewire).
@drmibell - ONE solution I use is to create a closure containing the data.
Basically, in a function node, you create an object.
Then you create a function which returns this object.
Put the function in global, and then NR will state 'function' for the global entry in the UI.
When the function node ends, JS can't remove the object because it's referenced by the function you created, which is in turn referenced by global.
But from anywhere in NR, you can call the function to get the object, and modify it's contents.
I have used this kind of approach to hide the aforementioned noble (BLE) structures, and also OpenCV images.
More advanced uses include making the function you create into a 'class', which allows you to call functions on a returned object, including removing the object you may no longer want to store :).
best regards,
Simon
