Node-RED runtime latency during high-volume Debug node output

Answer

The Debug node adds latency primarily by sending each message over a socket.io connection to the editor UI. The UI must JSON‑stringify the msg object and update the debug sidebar, which runs on Node‑RED’s single‑threaded event loop. When the message rate is high, this work blocks the loop and delays subsequent flow execution.

Likely explanation

Each Debug node emission triggers a socket.io event, serialization, and DOM update. The CPU time spent on these steps adds directly to event‑loop latency; latency grows roughly linearly with messages per second until the loop is saturated.

Confirmed facts

• Debug node output goes to the editor via socket.io; closing the sidebar or running headless removes this overhead.
• Setting the Debug node to output only msg.payload (complete:false) reduces the size of the serialized object.
• High‑frequency logging creates many short‑lived objects; if payloads are large, allocation rate rises and can trigger incremental GC pauses, adding occasional stalls.
• Node.js versions before 12 have less efficient loop handling, but upgrading does not eliminate the UI‑related blocking.

Steps to mitigate

1. Close the debug sidebar or start Node‑RED in headless mode (node-red --settings ./settings.js with httpNodeRoot: false or simply omit the editor).
2. In the Debug node config, set Output to msg.payload only.
3. Add a rate‑limit node (or a function that drops excess messages) upstream of the Debug node to cap messages per second.
4. Replace the Debug node for production logging with a file‑based node (e.g., node-red-contrib-file) or a function node that uses console.log; this bypasses socket.io entirely.
5. Monitor event‑loop delay with the admin API (GET /events) or a simple setInterval that logs Date.now() - lastTick to correlate spikes with debug bursts.

Missing diagnostic detail

Are you observing the latency with the editor UI attached (sidebar open) or when Node‑RED is running headless? Knowing this determines whether UI‑related socket.io work is the primary cause and whether headless mode alone would resolve the issue.