"Many web servers, for example achieve concurrency by creating a new thread for every connection. In most platforms, this comes at a substantial cost. The default stack size in Java 512KB, which means that if you have 1000 concurrent connections, your program will consume half a gigabyte of memory just for stack space. "
As a WebLogic developer we fixed this in the late 90s but the Volano chat benchmark was still run for no apparent reason. Somehow everyone else didn't get the message until Netty was released and people started using it.
Obviously what you want is multi-threaded execution with asynchronous I/O. Using node on multi-core systems just doesn't make a lot of sense as you end up having to duplicate your entire program on each core to get the full performance of the machine. Not unlike 512k/thread but much worse — especially if you cache anything locally in the process like template compilation, etc.
If you're going to just duplicate your process across all the cores then yes, local caching becomes an issue. Which was solved with Redis. Back in 2009.
Don't get me wrong, the fact that Node doesn't have a more efficient way of handling overhead on multicore machines is a drawback. But you pay for your abstractions. Nobody is going to argue that Node is a phenomenal solution for lightweight, multi-threaded execution. But most companies using Node seem to accept this and are fine with not utilizing 100% of their resources (hell, most don't even seem to know Node can spawn processes, in my experience).
If they care they use a framework that meets their needs.
Comments
"Many web servers, for example achieve concurrency by creating a new thread for every connection. In most platforms, this comes at a substantial cost. The default stack size in Java 512KB, which means that if you have 1000 concurrent connections, your program will consume half a gigabyte of memory just for stack space. "
As a WebLogic developer we fixed this in the late 90s but the Volano chat benchmark was still run for no apparent reason. Somehow everyone else didn't get the message until Netty was released and people started using it.
Obviously what you want is multi-threaded execution with asynchronous I/O. Using node on multi-core systems just doesn't make a lot of sense as you end up having to duplicate your entire program on each core to get the full performance of the machine. Not unlike 512k/thread but much worse — especially if you cache anything locally in the process like template compilation, etc.
If you're going to just duplicate your process across all the cores then yes, local caching becomes an issue. Which was solved with Redis. Back in 2009.
Don't get me wrong, the fact that Node doesn't have a more efficient way of handling overhead on multicore machines is a drawback. But you pay for your abstractions. Nobody is going to argue that Node is a phenomenal solution for lightweight, multi-threaded execution. But most companies using Node seem to accept this and are fine with not utilizing 100% of their resources (hell, most don't even seem to know Node can spawn processes, in my experience).
If they care they use a framework that meets their needs.