3 ms·
> On each server, rules are retrieved from Redis and cached in-memory using an LRU-cache. As node.js is not multi-threaded, we spin up 4 instances of node.js pe
by suzzer99 10y ago
> On each server, rules are retrieved from Redis and cached in-memory using an LRU-cache. As node.js is not multi-threaded, we spin up 4 instances of node.js per server, 1 instance per CPU core. Thus, we cache in-memory 4 times per server. This is a waste of memory!
This is completely standard and the only way to do node in-memory caching. Think of each worker as a completely independent node process, which is only bound to the cluster by a master process which has the ability spawn and kill child cluster processes.
- mi100hael 10y agoSeeing as Redis is already in-memory and has a LRU-cache feature, and he's already caching data from a database in Redis, the whole Node LRU seems awfully redundant and unnecessary.
- vkjv 10y ago> This is completely standard and the only way to do node in-memory caching. This isn't accurate you can use shared memory. There are a few modules that implement this. In addition, you can offload the JSON.parse to the dedicated "caching" process that updates the shared memory.
- suzzer99 10y agoDo you have a link that describes an example of this? Ok nevermind, google is my friend: https://github.com/PaquitoSoft/memored https://github.com/PaquitoSoft/memored I can see where this would come in handy. But at 240MB total resident memory per CPU across 4 node workers that OP describes, I wouldn't hassle with it.