As for asynchronous I/O and single threading, I think there are three ways to summarize why Node.js puts its talent in these two features.

1. User experience

From a front-end loading point of view, relatively straightforward. So why is JavaScript asynchronous? ! Instead, we thought about what would happen if JavaScript were synchronous. Request a user management page, load several resources with JS, first load a user profile picture, and then load the second, the third… GG, the user thinks the card is dead, and shuts it off without a word. (In Depth, it is mentioned that if the script time exceeds 100 ms, the user will feel stuck. JavaScript running on a single thread also shares a process with UI rendering. In practice, JavaScript asynchrony eliminates/attenuates UI blocking and the total loading time is X+Y+Z in synchronous mode and Max (X+Y+Z) in asynchronous mode. In addition, “Depth” mentioned in the current network development, distributed application popularity, the value of XYZ in front of the growth, so you can imagine that X+Y+Z and Max (X+Y+Z) gap is definitely getting bigger and bigger. It can be seen that asynchronous method is good, we all say cock! Node.js will choose asynchronous I/O, from the back end to asynchronous, improve resource response speed, then the front-end user experience will be better!

                                    

2. System resources

A set of tasks that need to be executed can be executed in two ways: single-threaded serial execution or multi-threaded parallel execution.

Single-threaded serial execution, problem: synchronous blocking! I/O had to wait for the end of step X to proceed to step X+1 – the reason was early time-sharing systems: CPU turns to different user service (service units of time is time slice), A service to step out the first x, may go to service the first y B, after returning to belong to the time slice of A service, and then give A service x + 1 step (this also can tell why I/O needs to wait for, end of the previous step to execute the next step). In order to continue performing A, the context of the steps from X to x+1 needs to be maintained and swapped, and when there are many processes, performance degrades. A slow task slows down the entire process – isn’t that bad? No, the good thing is sequential programming, the logic is easier to express.

Multithreaded parallel execution, the problem is: programming to consider the lock, state synchronization, a little careless, home destruction!

Therefore, node.js’s solution is to use a single thread to avoid multithreaded deadlock, state synchronization and other problems; Take advantage of asynchronous I/O to keep single threads out of blocks for better CPU use. (Original sentence of Depth)

                                 

3. Application scenarios

Node.js features and their application scenarios seem to me to be each other’s problems and answers. Considering that Web apps are the most common I/O intensive tasks today, Node.js chooses asynchronous I/O, single-threaded and event-driven to enhance performance. It’s also node.js

These characteristics make it more suitable for I/O intensive application scenarios. (Depth explains and compares node.js’s suitability for computation-intensive tasks)

———————————————————————

Here are a few other things that struck me:

  • Depth also notes that increasing the number of processes in order to improve performance does not improve resource utilization. He used the example of “triple the number of servers”, here is an explanation I found from douban :(whether triple the number of servers can improve the performance) depends on the architecture of the system itself, not necessarily triple the number of servers can hold three times the number of users to order. As more servers are added, the cost of communication between them increases, and if there are central nodes, those nodes still become bottlenecks. In contrast to the highway traffic jam, adding servers is not a simple case of “four lanes to eight lanes”. It is likely that with the addition of more roads, 1) more intersections will be built and 2) more branch roads will lead to more congestion on main roads.”
  • If you dig deeper into asynchronous I/O, The third chapter of Depth takes a closer look at how asynchrony can be implemented and how Node implements asynchronous I/O. Asynchronous is the ideal non-blocking asynchronous I/O:



(From Node.js)

When it comes to implementation, Node simulates this ideal in a multithreaded manner.



(From Node.js)

Wait, multithreading? Node is not JavaScript, is it single-threaded? I think I just slipped up. It has to be not. As mentioned in the Depth book, Node single-threaded refers to JavaScript running in a single thread, while Node’s asynchronous I/O is implemented by thread pooling/multithreading.
  • Node.js has the characteristics of asynchronous I/O, so it can be arbitrary, as long as asynchronous must be non-blocking? The answer is definitely no. If we do too many tasks on the main thread, or too many computationally intensive tasks, then the main thread may freeze up, affecting the overall performance of the application, which will block your asynchronous steps.


If there is any wrong summary, I hope we can communicate together!