Performance-related concerns regarding Node-RED

Hi everyone,

performance-related concerns regarding Node-RED. Specifically, I’d like to know if Node-RED has an LRU (Least Recently Used) cache mechanism implemented?

While reviewing the setup, I noticed that the lru-cache package is installed, which appears to be a peer dependency of the mqtt module. However, it’s not immediately clear whether this package is actively used by Node-RED itself for caching purposes or is limited to MQTT functionality.

Additionally, I’m curious about how Node-RED handles memory management for flows. Are there specific strategies in place for clearing or managing the flows stored in memory? For instance:

  • Is there a built-in mechanism to unload inactive or unused flows to optimize memory usage?
  • How does Node-RED ensure that memory consumption remains stable, particularly in systems with high-flow throughput or prolonged uptime?

Any insights or resources to better understand this aspect of Node-RED’s architecture would be greatly appreciated.

Thanks in advance!

This question was also asked on slack where I have responded.

I'm reproducing my reply (expanded slightly based on the slack conversation) here to save others the time...

Node-RED does not have any caching of the sort you are interested in. All nodes are started when the runtime starts, and are only stopped when the runtime stops or new flows are being deployed.

There is no built-in mechanism for unloading nodes that have been inactive. It is not a simple problem to identify if a node is 'inactive' - just because it hasn't sent/received a message, it doesn't mean it is inactive. For example, a node could be monitoring an external resource - the runtime has no insight into that.

It leaves memory management to the node.js runtime.

2 Likes