6 ms·
It's not radical, it's just occasionally more confusing than blocking io to implement, and doesn't really have any performance benefits in the multicore world.
by jbooth 15y ago
It's not radical, it's just occasionally more confusing than blocking io to implement, and doesn't really have any performance benefits in the multicore world.
I'm actually using node for a side project right now as part of re-learning web development (been back-end the last few years), and using javascript as a client language, server language, and db query language via mongo is a neat environment. Also, npm rocks. But don't listen to anyone who tells you they use node+mongo to handle their WEB SCALE PERFORMANCE. If they really had that problem, they'd be better off using the java ecosystem or, if they really wanted to go hardcore, using a lot of C. But Java's unfashionable and C's ridiculous to write a web app.
- mcantelon 15y ago>doesn't really have any performance benefits in the multicore world AFAIK, Node's cluster API, which can spawn workers for each of a machine's cores, will, when delegating requests to a worker, factor in OS-level core utilization info.
- jbooth 15y agoFrom what I could tell, that spawns actual child processes and communicates with them over pipes. Fine from an architectural standpoint, but a penalty compared to shared memory from a performance standpoint. And it still has the problem of a single heavy CPU request on a given worker blocking all the requests behind it on that worker. Again, I'm not saying node sucks, I'm using it and I like it. I'm just saying if you really need to crank out performance, use java.util.concurrent, or maybe Go. They both offer event-driven i/o if you really want it, and have better threading models.