Understanding the event loops of node. js

The first basic point of view of node. JS is that I/O operations are expensive:

The biggest waste of current programming technology comes from waiting for I/O operations to complete. There are several ways to address these effects on performance (from Sam rushing):
　　synchronization : Processes a single request in turn.
Pros: Simple.
Disadvantage: Any one request will block the remaining requests.
　　Create a new process : Create a process handler for each request
Pros: Easy.
Cons: Poor scalability, hundreds of connections means hundreds of processes. Fork () is a Unix Programmer's hammer. Because it's useful, all the problems are like nails. But this is usually superfluous.
　　Threads : Creates a threading process for each request.
Pros: Easy; Because threads are usually very small in cost, they are more friendly to the kernel than using fork.
Cons: Your machine may not have threads, and threading programming can easily become complex, and there are problems with how to access shared resources.

The second basic idea is that a single-threaded connection consumes memory very much.

Apach is multithreaded: Creates a thread (or process, depending on the configuration) for each request. You can see how increasing the current number of connections consumes memory, and multiple threads need to serve multiple customers at the same time. Nginx and node. JS are not multi-threaded, because multithreading and multi-process can cause heavy memory overhead. They are single-threaded, but event-based. Resolves overhead issues for thousands of threads/processes by single-threaded processing of multiple connections.

node. JS maintains a single-threaded running environment for code

node. JS is really single-threaded: You can't execute any concurrent code, such as "sleep," which causes the server to stop.

When the code is running, node. JS does not respond to other requests from the client because it has only one thread executing the code. Or you can use some cpu--intensive code, such as resizing a picture, which still blocks other requests.

However, all code can be executed in parallel

There is no way to run the code in parallel in a single thread. In addition to all I/O operations and asynchronous events, the following code does not block the server: [Codesyntax lang= "JavaScript"]

Execute the above code in one request, and the database can be handled well when it sleeps.

What good is this? When should we change the synchronization to asynchronous/parallel execution?

Synchronous execution is a good approach because it makes coding easy (concurrency issues result in wtfs compared to multithreading).

In node. js, you don't have to worry about what's going on in the background: just use callbacks to perform I/O operations, which ensures that your code is not interrupted, that I/O operations do not block other requests, and that each request does not increase the cost of threads/processes (for example, memory overhead in Apache).

asynchronous I/O operations are also a good approach because I/O operations are more expensive than most code execution, and we should do other things instead of waiting for I/O operations

A time loop is "an entity that can process and process external events and convert them into callback calls." So the key to I/O calls is that node. JS can switch from one request to another. In an I/O call, the code saves the callback function and returns control to the runtime environment of node. js. The callback function is called when the data is available.

Of course, in the background, there are threads and processes for database access and execution processes. However, this does not expose the code, so you do not need to worry about I/O operations, for example, the database or other processes are asynchronous for each request, and the execution results of those threads are returned to the code through the event loop. There is no need to provide a single thread for each connection compared to the Apache model, which requires less thread and thread overhead, and only if you really need to run it in parallel, even if management is able to run in node. js.

In addition to calls to I/O operations, node. JS expects all other requests to respond quickly, for example: cpu-intensive work should be split into the process of interactive events, or as abstract as webworkers. This means that there are no other threads running interactive events concurrently in the background. Basically, all listener event objects (all instances of Eventemitter) support asynchronous interaction events, and you can interact with blocking code in this way, such as using files,sockets or sub-processes, which are eventemitters in node. js. [Multi-core] [8] This method can also be used, see: Node-http-proxy

Internal implementation

Internally, node. JS relies on Libev to implement the event loop, with Libeio as a helper, and using mixed threads to implement asynchronous I/O operations. To learn more, you need to review Libev's documentation.

How do I use async in node. js?

Tim Caswell described this pattern in his excellent speech:

The first-class function. For example, we pass functions as parameters and execute them when needed.
Function form. Also known as an anonymous function or a closure function, executed when the i/0 operation is complete.

Original: Understanding the node. js Event Loop

Understanding the event loops of node. js