Good afternoon. I am discovering node-red. I currently work in a city that has more than 200 water installations, with PLCs (automation devices) that send and receive data every 5 seconds. I would like to know if nodered could replace systems such as keepserver or other physical devices that allow databases to communicate with plc and other devices. What is the node-red limit? Is it possible to use with thousands of data that come and go endlessly?
The short answer is yes. The long answer needs more info like is what make and model of plc?
Please don't forget that any answer also needs to take into account security and resilience. While Node-RED may be more than capable of handling the data exchanges, you would need to be certain that you had secured the flows, the server, the networking, the connections, ...
The last thing you would want would be for a virtual rat to get into your water supply controls for an entire city.
You're right. Currently, as I am discovering node-red, I first want to confirm that its potential is sufficient, such as Keepserver or other alternatives. Once I am sure of it, I will have to know the tool well and above all, as you say, study all the security so that there are no problems.
I would like to know examples of installations to confirm the power of node-red. Or that you know specific data on processing capacity, etc.
Thank you very much.
Capacity of Node-RED is going to depend significantly on what you are running it on and what else might also be running. It will also somewhat depend on how much data is in each msg your PLC's are sending.
You might also be able to tune things by ensuring a spread of incoming data from the PLC's but that depends on how they can be controlled (if at all).
Other factors will include the network you are using and the PLC's ability to send data over it.
On my dev PC (Intel i9, 16GB RAM, Windows 10), I recently added a proof-of-concept MQTT logger which I had to add a delay node to limit sending of msgs to a uibuilder front-end (over Socket.IO) of 10,000 messages per second. I didn't actually measure the CPU usage. The broker was running on another PC, both connected via 100MBps ethernet. Not sure what the bottleneck was, but the initial load of the client dumps a very large number of MQTT messages at once. Not helped by the fact that I have a Node-RED custom log outputting msgs to MQTT which were then coming back into the MQTT viewer and causing a loop 
Once I got rid of that initial load loop, the first dump of data takes a second or two and then has no problem keeping up with the 4-5k per minute inbound and 7-8k per minute outbound messages of various size and complexity.
So relatively modest server resources (CPU/memory) should easily cope with thousands of messages per second. You could further tune that by using relatively local small devices such as a Pi to gather local data and only send actual changes on to a central hub. I believe that there have been other reports of even Pi's handling thousands of messages per second.
Just remember though that Node-RED is a node.js app and that node.js is mostly single-threaded. While it is generally very good at hiding this, occasionally you may hit something that causes the thread to be delayed. More commonly, trying to handle more data in-memory than your device can accommodate will cause periodic delays due to Node.js's garbage collection routine kicking in.
Resource optimisation for node.js apps is quite complex and generally the best approach seems to be "give it a go" then look for potential slow-downs if necessary.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
