[ralusek]

For concurrent asynchronous tasks, being single threaded or multithreaded shouldn't make any meaningful difference. To make a million concurrent asynchronous calls on a single thread takes couple MS, to make on multiple threads takes about the same. For concurrent SYNCHRONOUS tasks, being single threaded or multithreaded makes a huge difference, but that's not what we're talking about here. It's also not at all fair to call NodeJS single-threaded in regards to its concurrency model, as it utilizes all cores through parallel application instances.

[lod723]

The multiprocess Node concurrency model is brittle and fault intolerant. The event loop scan actually has real bottlenecks at a certain level of fds in flight. A real scheduler really wins here; libuv sits below the knowledge of the runtime to really be optimal. You become CPU bound far sooner than you expect.

With a global heap, you also become memory bound far sooner than you expect as well.

[chrisco255]

Your typical Node instance is using an order of magnitude less memory than the beastly JVM. We use Java microservices with Spring at my job and each "micro" service consumes close to 1GB of memory. I've never written a Node service that had more than 100MB footprint.

[empthought]

The default maximum heap size for the JVM on systems with 4GB or more of RAM is one gigabyte. Has this been changed in your microservices' startup parameters? If not, it is no surprise that Java uses the memory that you have allocated to it before garbage collecting.

Spring Boot microservices that don't do much shouldn't need more than 32MB heap -- see https://spring.io/blog/2015/12/10/spring-boot-memory-perform... for details.

[lod723]

The JVM has the same global heap problem as Node... it's frustrating that with all the development that goes into the JVM this problem remains unaddressed.