Analysing the Performance of Node-RED

Published: | Updated: | by Julian Knight Reading time ~3 min.
📖 Kb | 📎 Development | 🔖 node-red, node.js, javascript, debugging, performance

Node-RED is a powerful platform for prototyping and rapid development but it is complex. It has a lot of moving parts and it can be hard to know what might be causing performance bottlenecks. This article tries to give some hints and tips about analysing those bottlenecks and how to resolve them.

Sorry, this is draft and far from complete. Please leave comments if you have something useful to add. Thought I would publish anyway in case anyone finds it useful. I will try to come back to it in the future. If you leave a comment, it will remind me. :-)

Platform 🔗︎

Before starting more detailed analysis, the first thing to do is to look at the platform being used to run Node-RED.

Often, something like a Raspberry Pi or other single-board computer (SBC) is being used. They have very limited resources and often slow storage (e.g. SD-Cards). So it is very easy to overload them and kill performance.

To analyse this, you need to use a tool such as top. Better still, get something a bit more comprehensive such as glances. Either way, these will tell you how much CPU and memory (RAM) is being used and by what. Start by looking at the three ‘load’ values, these should all be fairly low, if they are going over about 2-3 regularly then you have an issue.

Next look at the ‘swap’. If this is being used regularly, you will have a performance bottleneck because memory (RAM) is being overused. To fix this, you have to unload some services. If using the glances tool, it will show a warning if the memory is swapping.

The easiest way to remove load is likely to be turning off the ‘desktop’. This gives you a GUI that you directly interact with via keyboard and monitor. Removing this will remove lots of load on memory and CPU. Have a look at articles that explain how to run your device ‘headless’. You will need to be able to connect to your device over the network from another device.

After that, if there are still issues, you need to look at taking off services that you don’t actually need running.

Finally, if you still have issues, you will need to think about splitting services between multiple devices or using a more powerful device.

Back End (server) 🔗︎

Using Node.JS --inspect option 🔗︎

Front End Browser (Node-RED Admin UI) 🔗︎

For any browser performance issues, you firstly need to ensure that the problem is actually coming from something related to Node-RED. So you should turn off any browser extensions before continuing. An extension such as SimpleExtManager for Chromium browsers will assist with easily turning on/off extensions.

Browser Performance Profiling 🔗︎

Using your browser’s developer tools, you are able to record and analyse a performance analysis. The Chromium developer tools have three tabs to help with this. Performance, Memory and Application.

The Performance tab is perhaps the easiest to get going with. Click on that tab and then start profiling. Leave that for an amount of time that you estimate will let you see any ongoing performance issues. That might be just a few seconds or a few minutes. You will want to tick the “memory” option and probably don’t need the “Screenshots” option.

The thing to look at first is likely to be the memory utilisation. There is a graph 12 way down the display that shows you some important metrics including the “JS Heap”. See how big that is getting by hovering over the line. Also look at how fast it is growing. You should see that the heap reduces periodically as the JavaScript engine does a ‘garbage collection’.

You can also do multiple recordings and compare the heap over a longer period.

Front End (Dashboard, uibuilder, http-in/-out nodes, etc.) 🔗︎


comments powered by Disqus