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 
?
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).
