Easy way to remove lag?

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

Don't make it node-RED's fault.
Do you carry any responsibility in terms of learning how to work with a tool ?

Talking of abusing everything. Also be very careful about putting functions into context. Will probably work if in memory. But if context is in some other storage then the function won’t serialise

@bakman2 - haha - yes, I was admit I push it above and beyond :). Fell in love over 2 years ago, and now use it (and abuse it) for everything I do... commercially as well as personally. Only by pushing the limits can you really find the limitations - and I'll be the first to admit that I'm not a 'typical user'. Also, if it was a serious fault in NR which affected me, I'd fix it and contribute given time. Yes, I highlight a limitation in NR - for typical use it's not a problem, but when faced with an issue like the OP, I share my experience of similar situations I've faced in the hope that it may help them.
p.s. by 'when I found the issue', i meant 'when i found the issue in my flow' :).

@dceejay - yep, I won't be using the features of any version which shares across machines any time soon - not without a degree of rework :). I hope i'm not just being hopeful that everything in 0.17 is within one process?

@hotnipi - having re-read, i should make it plain, this is NOT dashboard data; it's data to the web editor UI, over which you have no control (apart from not putting the data in messages/global/flow/context in the first place).

Shouldn't we try to find the answer to the question what should the user do when the performance drop tells that limits on some or another way seems to be reached?

I think that what we've all discovered between us is that there isn't a single answer.

So what we really need to do is to capture the various things that people have done in a way that is easy for others to work through the ideas?

Is there perhaps room for a "performance" group here in Discourse? Or some part of the GitHub WIKI for Node-RED? Or the cookbook? Or somewhere else?

Performance issues tend to sneak in so the "Oh I know I did this thing wrong" experiences are most probably rare. To get out of this kind of trouble is not easy task. Main thing is that description the user can give about the running combo may not always be clear enough to identify root causes. So the thing that might help here should be step by step list of things to do and how to collect the data to fulfill the list of base data the educated person then can take a look and make fair assumptions and avoid guesswork. Such WIKI page or something.

Agree that a WIKI page would be a sensible starting point for collating a set of approaches.

@knolleary or @dceejay, would you be happy with someone creating a WIKI page either on the main Node-RED repo or maybe the cookbook repo?

If nothing else, we could use that as a place to link to other articles as a starter. Then we could think about the best way to present performance analysis tips to people.

Sure - go ahead.

Hitachi are in the process of translating to English a Flow development guide they produced for their users. You can see a number of PRs on the https://github.com/Node-RED/nodered.github.io repo.

I could imagine this sort of content ending up in there.

It is also important we identify concrete things NR could do better - and make sure they get captured. Such as the exchange with @btsimonh regarding the context sidebar (in that instance, I have added an item on the dev plan to add a toggle to the sidebar)

1 Like

One thing I have rarely done is debug Node-Red as a process (for normal stuff node.warn, console.log and util.inspect are usually sufficient), . A quick google brought these up:



I've only done it with the raw chrome debugger...
If process debugging approaches options are not well documented, then this could be a good thing to do.

One could imagine instrumenting function nodes and NR internals (clone, messaging, debug output, etc), and making a kind of 'task manager' style performance display to help tune flow performance; but in general I find projects which are over instrumented in this way annoying because I just think of the performance I'm losing because of the instrumentation!
(and apologies if I'm not aware of developments after 0.17)

There may also be mileage in investigating:


Maybe the internal profiler can be turned on and off in real time, and the data captured for analysis - you could image a flow to do this and display on dashboard :slight_smile: ?

Note also that @BartButenaers has a number of nodes relating to performance analysis. We used some of these when looking at OpenCV related topics.

Thanks Nick.

I've added the links from the post above and some draft text from a blog article that I'd been starting (that I will kill off now in favour of the WIKI post).