3 ms·
I'm likely missing some nuance here - the QEWD setup described sounds exactly like the model used to load-balance across multiple single-threaded application se
by al2o3cr 10y ago
I'm likely missing some nuance here - the QEWD setup described sounds exactly like the model used to load-balance across multiple single-threaded application servers in most environments that aren't Node: lightweight, highly-concurrent front-end server dispatches requests to a pool of single-threaded application servers. This architecture was well-known back when Node was created, so I assume they chose a different architecture for a good reason.
Is there a prefork-friendly GC for Javascript? I know this was a major issue with the many-single-threaded-app-servers approach in the Ruby ecosystem; previous versions of the GC algorithm kept GC metadata in the same pages as data, preventing the CoW memory sharing that prefork servers ideally prefer.
- robtweed 10y agoYou're right - the QEWD architecture is as you describe, and not that unusual, though I'm not aware of anyone else having implemented such a design with Node.js. I'm not sure there was a good reason for Node's not using something similar, but then again, I'm not really proposing that Node.js should be like QEWD. The fact is I've been able to implement QEWD's architecture using standard Node.js capabilities. So it provides a way of working around the deficiencies of Node that are a direct result of its intentional architecture, if that's what you want to be able to do - best of both worlds. Not sure I understand your GC questions, sorry?