How and when is the single threaded asynchronous processing model of nodejs a better approach than the multithreaded approach of the known server Gurus like PHP, Java and C#?. Can someone please explain to me simply and clearly?
My question is how technically is the single threaded asynchronous processing model a better approach ?
Grasping the Node JS alternative to multithreading
Node.js was created explicitly as an experiment in async processing. The theory was that doing async processing on a single thread could provide more performance and scalability under typical web loads than the typical thread-based implementation. The single threaded, async nature does make things complicated. But do you honestly think it's more complicated than threading? One race condition can ruin your entire month! Or empty out your thread pool due to some setting somewhere and watch your response time slow to a crawl! Not to mention deadlocks, priority inversions, and all the other gyrations that go with multithreading.
But is it really single threaded. Read this article https://softwareengineeringdaily.com/2015/08/02/how-does-node-js-work-asynchronously-without-multithreading/
Node.js is built on top of Google's V8 engine, which in turns compiles JavaScript. As many of you already know, JavaScript is asynchronous in nature. Asynchronous is a programming pattern which provides the feature of non-blocking code i.e do not stop or do not depend on another function / process to execute a particular line of code.Asynchronous is great in terms of performance, resource utilization and system throughput. But there are some drawbacks: Very difficult for a legacy programmer to proceed with Async. Handling control flow is really painful. Callbacks are dirty.
NodeJS is single threaded and it is not a deterrent or a performance block really. The single threaded event loop is super efficient and is much less complicated than deploying effective multithreading. Multi-threading does not always mean better performance.
Having said that, if you do need to handle heavy concurrency, then you can employ the services of the cluster module which splits multiple NodeJS processes across available CPU cores, all the while maintaining a link with a master process which can be used to control/offload processing tasks.
Node was built from the ground up with asynchronicity in mind, leveraging the event loop of JavaScript. It can handle a lot of requests quickly by not waiting around for the request when there are certain kinds of work being done for the request, such as database requests.
Imagine you have a database operation that takes 10 seconds to complete, represented by a setTimeout
router.route('/api/delayed')
.get(function(req, res) {
setTimeout(function() {
res.end('foo');
}, 10000);
});
router.route('/api/immediate')
.get(function(req, res) {
res.end('bar');
});
or a back end framework that does not support asynchronous execution, this situation is an anti-pattern: the server will hang as it waits for the database operation to complete and then fulfill the request. In Node, it fires off the operation and then returns to be ready to field the next incoming request. Once the operation finishes, it will be handled in an upcoming cycle of the event loop and the request gets fulfilled.
As long as we only write non-blocking code, our Node server will perform better than other backend languages
After reading about it in the book: Web Development with MongoDB and Node.js 2nd Edition by Maithun Satheesh, Jason Krol and Bruno Joseph D'mello, I finally came across a clear advantage
To understand this, we should understand the problem that Node.js tries to resolve. It tries to do asynchronous processing on a single thread to provide more performance and scalability for applications that are supposed to handle too much web traffic. Imagine web applications that handle millions of concurrent requests; if the server makes a new thread for handling each request that comes in, it will consume a lot of resources and we would end up trying to add more and more servers to increase the scalability of the application. The single threaded asynchronous processing model has its advantage in the previous context, and you can process much more concurrent requests with less number of server-side resources.
And I notice that one can process much more concurrent requests with less serverside resources
my 2 pence worth.... i am not sure sure "if the the single-threaded approach of nodejs is better" : simply put, nodejs does not support multi-threading. that can translate loosely to " everything runs in a single thread". Now, I am not quite sure how it can "compare" to a multi-threaded system , as a "multi" threaded system can support both as a single thread (like nodejs ) and multiple threads . Its all in your application design , and the platform capabilities that are available to you.
What is more important, in my opinion, is the ability to support multi-tasking, in an asynchronous way .Nodejs, does provide support for multi- tasking, in a simplified and easy-to use package. It does have limitations on due to the lack of native support for multi-threading. to take advantage of the multi-tasking ( and not worry.. much ) about multi-threading, think along the lines of designing your serverside application as performing little chunks of work over a long period of tie , and each chunk of work is invoked, and consuming events generated from the clientside . Think an event-driven design/architecture ( simple switch/case for loops, callbacks, and data checkpointing to files or database, can do the trick). And I will bet my tiny dollar , that if you get your application to work in this fashion, sans multi-threading, it will be a much better design , more robust, and if you migrate it ( and adapt for multi-threading ) it run like on an SpaceX buster!
While multi-threading is aways a plus for serverside implementation, it is also a powerful beast that requires a lot of experience and respect to tame and harness ( something that nodejs shields/protects you from)
Another way to look at is is this : Multi-tasking is a perspective ( of running several tasks) at the application level , which multi-threading is a perspective, at a lower level : Multi-tasking can be mapping on to different implementations, with multi-threading being one of them .
Multi-threading capability
Truth : Node.js ( currently ) does not provide native support for multi-threading in the sense of low level execution/processing threads. Java, and its implementations /frameworks, provides native support for multi-threading, and extensively too ( pre-emption, multi-tenancy, synchronous multi-threading, multi-tasking, thread pools etc )
Pants on Fire(ish) : lack of multi-threading in Nodejs is a show stopper. Nodejs is built around an event driven architecture , where events are produced and consumed as quickly as possible. There is native support for functional call backs. Depending on the application design, this highlevel functionality can support what could otherwise be done by thread. s
For serverside applications, at an application level , what is important is the ability to perform multiple tasks, concurrently :ie multi-tasking. There are several ways to implement multi-tasking . Multi-threading being one of them, and is a natural fit for the task. That said, the concept of “multi -threading “ is is a low level platform aspect. For instance multi-threaded platform such as java , hosted/running on a single core process server ( server with 1 CPU processor core) still supports multi-multi at the application level, mapped to multi-threading at the low level , but in reality , only a single thread can execute at any ontime. On a multi-core machine with sa y 4 cores , the same multi-tasking at application level is supported , and with up to 4 threads can executing simultaneously at any given time. The point is, in most cases, what really matters is the support for mult-tasking, which is not always synonymous with multi-threading.
Back to node.js , the real discussion should be on application design and architecture , and more specifically, support for MULTI-TASKING. In general, there is a whole paradigm shift between serverside applications and clientside or standalone applications, more so in terms of design, and process flow. Among other things, server side applications need to run along side other applications( onthe server ), need to be resilient and self contained (not affect the rest o f the server when the application fails or crashes ) , perform robust exception handling ( ie recover from errors, even critical ones ) and need to perform multiple tasks .
What else for Node.js vs Java
