3 ms·
I don't understand these strawmans. The virtue of the asynchronous programming model is low-memory overhead as compared to threads AND low latency for IO-bound
by eldude 11y ago
I don't understand these strawmans. The virtue of the asynchronous programming model is low-memory overhead as compared to threads AND low latency for IO-bound tasks in highly concurrent scenarios.
Request per-process/thread has all the same memory overhead implication it has always had. It's almost like the author is ignorant of the reason for node.js' success or why it was built in the first place.
Also, "callback hell" is just FUD. Nobody who does this for a living and knows what they're doing really has an issue with this. Promises solve the unreliability issues, and async/await solves the syntax complexity issues.
I'd like to see this same analysis for 1000 req concurrency measuring memory overhead and using async/await for code comparison. Cooperative multitasking will always be capable of lower latency when you know what you're doing, and async programming is lightyears simpler than multi-threaded programming.
- tracker1 11y agoI'd say at least 10K simultaneous requests on a single instance with ease, let alone several. Just a simple echo web-server... http://localhost/foo http://localhost/foo => "hello foo" ... Launching that many threads will quickly hit bottlenecks on most systems... I've seen this happen in a poorly written simulation server (each actor had it's own work thread)... the server would freeze up randomly with only a handful of connections in a test scenario... changing to an event-loop using an async thread-pool resolved most of these issues (this was before node).