Understanding Node. js event Loops

An article on node. js event loops. Original Article Source: Click to jump!

Before learning about node. js, you must first understand the basic argument that I/O is "expensive.

Therefore, for the current programming technology, the biggest waste comes from waiting for I/O to complete. The following lists several ways to improve the problem, one of which can help you improve performance:

• Synchronization: only one request is processed at a time. However, in this case, all other requests will be "congested.
• Fork is a new process: for each request, you start a new process to process it. In this case, the expansion cannot be achieved, and hundreds of connections mean the existence of hundreds of processes. The fork () function is a hammer for Unix programmers. Because it is very convenient to use, every program looks like a nail (like hitting it with a hammer ). Therefore, it often leads to excessive use, and some past corrections.
• Thread: Start a new thread to process each request. This method is very simple, and the use of threads in the kernel is also more "friendly" than the fork process, because the thread usually costs less than the process. Disadvantages: Your machine may not support thread-based programming and thread-based programs. The complexity of the programs increases rapidly, and you may also worry about accessing shared resources.

The second argument you need to understand is that every connection processed by the thread is "memory expensive ".

Apache uses multiple threads to process requests. It "incubates" a thread (or process, depending on the configuration) for each request. As the number of concurrent connections increases and more threads need to serve multiple clients, the overhead will consume more memory. Nginx and Node. js are not based on the multithreading model, because both threads and processes require a high memory overhead. They are all single-threaded, but event-based. This single-threaded model eliminates the overhead of creating hundreds of threads or processes to process many requests.

Node. js maintains a single-threaded runtime environment for your code

It is indeed based on a single thread, and you cannot write any code to execute concurrency. For example, executing a "sleep" operation will block the entire server for 1 second.

while(new Date().getTime() < now + 1000) {   // do nothing}

Therefore, when the code runs, node. js will not respond to other requests from the client, because it only has one thread to execute your code. Or, if you have some CPU-intensive operations, such as resetting the image size, it will block all other requests.

... However, everything except your code is Concurrent executionOf

In a single request, there is no way to execute code in parallel. However, all I/O operations are time-based and asynchronous, so the following code will not block the server:

c.query(   'SELECT SLEEP(20);',   function (err, results, fields) {     if (err) {       throw err;     }     res.writeHead(200, {'Content-Type': 'text/html'});     res.end('


If you do this in a request, other requests can be executed very well.

Why is this a better way? When do we need to switch from synchronization to asynchronous/concurrent execution?


Synchronous execution is a good method because it makes coding easier (compared with threads, concurrency problems often make you stuck in the box ).
In node. js, you do not need to worry about the occurrence of your code on the backend. You only need to use the callback when you perform I/O operations. You will be guaranteed that your code will not be interrupted, and I/O operations will not block other requests (because there is no overhead required by those threads/processes, for example, the memory usage in Apache is too high ).
Asynchronous I/O is also good, because I/O is more expensive than other operations, we should do something more meaningful than waiting for I/O.





An event loop refers to an entity that can process external events and convert them into callback execution. Therefore, I/O calls become node. js can switch from one request to another. Your code saves the callback and returns control to node. js runtime environment. The callback is executed after the data is finally obtained.
Of course, in node. js, data is still accessed and processed by threads and processes. However, these are not explicitly exposed to your code, so you do not need to worry about how to handle the interaction between I/O internally. Compared with the Apache model, it reduces multithreading and thread overhead, because separate threads are not required for each connection. The thread is required only when you absolutely need to execute an operation concurrently, but even so, the thread is also managed by node. js itself.
Besides I/O calls, node. js expects that all requests should be returned quickly. For example, CPU-intensive jobs should be isolated to another process for execution (by interacting with events or using abstractions like WebWorker ). This obviously means that when you interact with events, if there is no other thread at the backend (node. js runtime), you cannot execute code in parallel. Basically, all objects that can be emit events (such as EventEmitter instances) both support event-based Asynchronous interaction and you can also interact with "blocking code" (such as using files, sockets, or in node. js is a sub-process of EventEmitter ). If you use this solution, you will be able to benefit from the advantages of multi-core. You can see: node-http-proxy.


Internal implementation

Internally, node. js depends on the event loop provided by libev. libeio is a supplement to libev. node. js uses pooled threads to provide support for asynchronous I/O. For more details, see the libev documentation.

How to Implement Asynchronization in Node. js



Tim Caswell described the entire mode in his PPT:


 

 
  
First-classfunction: for example, we transmit the function as data and wrap them for execution as needed.
 
  
Function Assembly: as you know about asynchronous functions or closures, it is executed after I/O events are triggered.
 
  
Callback counter: For event-based callbacks, you cannot guarantee that I/O events will be executed for any special commands. Therefore, once you need to perform multiple queries to complete a specific processing, you usually only need to count any concurrent I/O operations, then check whether all necessary operations have been completed when you really need the final result (one example is to count the returned database query in Event Callback ). The query will be executed concurrently, and I/O also provides support for this (for example, concurrent query can be implemented through the connection pool ).
 
  
Event loop: As mentioned above, you can wrap blockingcode into an event-based abstraction (for example, by running a sub-process and then returning it after it is executed ).

 
It's really easy!


Statement again Source: http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/
In addition, please refer to the famous "original Article Source" for reprinting this article. Thank you!