5 ms·
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.
by lod723 9y ago
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 9y agoYour 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 9y agoThe 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-performance https://spring.io/blog/2015/12/10/spring-boot-memory-perform... for details.
- deleted 9y ago[deleted]
- lod723 9y agoThe 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.