I am suspecting that the messages in the debug window (from the debug node) are coming slow. To test this, I made a simple python counter. The output in the terminal is very fast, while in the debug window it arrives with a delay of 1-1.5 seconds. As I am using those messages to trigger events, everything is slowed down.
this is my main block:
The link-out node is connected to a sort of 50-60 different flows. Could they be too much?
Where am I wrong?
How are you using debug output messages to trigger events?
Is the browser running in the same machine as node-red?
Is the processor being overloaded while this is going on?
Hi Colin.
Not really using the "debug" window, but as you can see from the sketch in my post, I have a link-out node connected to other 50 flows. The debug window is displaying messages very slow, and they are delivered slow to the other flows.
The browser is running on another machine and the processor (Raspi) has a load average of 0.5, very low.
How about the question?
Is the browser running in the same machine as node-red?
Don´t forget that the editor uses a WebSocket connection to get messages from the runtime. If the runtime is not in the same machine of the editor then it is normal that there will be a delay (messages over websockets). The messages you get in the console are not using websockets. If this is a system in production you should consider if the debug nodes should be there.
The debug window is the only mean I have to check if correct messages are flowing in the BUS.
The main flow of this project is monitoring a automation bus and then 50 flows are analyzing the result for each message, taking the right action if requested. The debug window gives me a sort of feedback.
Once you have it working, then remove the debug. As yes it will slow things down.
So you are using the output from the MQTT node to trigger the other flows, not the debug output. Where is the MQTT broker running?
Is the python code that runs fast picking the data up from MQTT?
Yes, the python code is running as a lightning (I can monitor it in the terminal or in MQTT-explorer). Mosquitto is running on same Raspi as NR.
If you remove the wire to the link node does the debug run ok? What speed are you sending data?
I will make the "remove wire" test asap (now the system is in production). Data is sent at variable speed, from 10 frames/second to 1 each 10 seconds..
@fmarzocca just an observation (not likely to cause any significant issue) but you should not start a topic with / See best practices here
Yes. It is very fast. So the problem is related to the link towards the other 50 flows, each of one starting with a switch node to intercept its related frame. I'm out of ideas now.
What are these 50 flows doing? Heavy computation? How big is the payload?
The flows are intercepting a frame and use it to trigger automation (lights/scenarios/blinds/curtains/etc..) Many of them are complex as they are sending status queries.
Is this "frame" 2 bytes, 1000000 bytes?
I ask because there will be 50 clones due to how you have arranged things.
What is "sending status queries" ? using what nodes? how big are the payloads?
If you dont say, we cant really help you realise if any of them are "blocking" or offer you alternative patterns to try out.
It's not easy to answer to some of your question....
The frame is short (from 6 to 10 characters).
Sending a query can be "ask to the burglar alarm which is its status, and wait for 10 frames as an answer for all zones" or maybe "check the status of the window contact"
Used nodes are mainly switch, change and tcp request (to send messages). Few (but simple) custom functions.
Flow.json is 500KB
If you run top (with the flows connected obviously) how much CPU are node-red and/or node using?
ranging from 0.4 (quiet state) to 3.4/3.7 on heavy load
What does wait 10 frames mean? Are you looping? Or doing something that is "blocking".
Based on what I've read in this thread - that looks like a strong possibility.
Could you share a flow?
It is odd that something appears to be blocking the nodejs message loop, but not consuming CPU. Assuming that is actually happening.
@fmarzocca can you see that the messages are being delayed by some other action they have rather than seeing output in the debug node?
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy