1. Why Node?

It is very simple by itself, organizing many nodes through communication protocols, and it is very easy to scale to achieve the purpose of building large network applications. Each Node process constitutes a Node in the network application, which is the true meaning of its name.

2. Can you tell me something about Node?

As a platform for running back-end JavaScript, Node retains the familiar interfaces of the front-end browser JavaScript, without rewriting any of the language’s features, and is still based on scope and prototype chains. The difference is that it migrates the ideas widely used in the front-end to the server side. Here’s a look at some of the features of Node compared to other languages:

1. The asynchronous I/O

Asynchronous I/O may be easier to explain to front-end engineers because making Ajax calls is a familiar scenario. The following code is used to make an Ajax request:

$.post('/url', {titlenode.js'}, function (data) {console.log(' received response '); }); Console. log(' send Ajax end ');Copy the code

Users familiar with asynchrony will know that “received response” is output after “sent Ajax finished.” After calling $.post(), subsequent code is executed immediately, and the execution time of “received response” is not expected. We only know that it will be executed after the asynchronous request ends, but we don’t know when. The capture of result values in asynchronous calls is consistent with the “Don’t call me, I will call you” principle, which is also a result – oriented, not process-oriented approach.

2. Events and callback functions

Node is not as heavily influenced by Java as Rhino, but brings the widely used and mature events of the front-end browser to the back end, along with asynchronous I/O, exposing event points to business logic.

In contrast, events are commonly used on both the front and back ends. For other languages, this familiar feeling of ubiquitous JavaScript is almost impossible.

3. Single thread

Node maintains the single-threaded nature of JavaScript in the browser. And in Node, JavaScript cannot share any state with other threads.

The biggest benefit of single-threaded programming is that you don’t have to worry about state synchronization everywhere, there are no deadlocks, and there are no performance costs associated with thread context exchange.

Also, single threading has its own weaknesses that you have to deal with while learning Node. By being proactive about these weaknesses, you can take advantage of Node’s benefits and avoid potential problems so that it can be used efficiently. The weakness of single thread has the following 3 aspects.

  • ❑ cannot utilize multi-core cpus.
  • ❑ errors cause the entire application to exit, and the robustness of the application is worth testing.
  • ❑ A large number of computations occupy the CPU, causing asynchronous I/O calls to fail.

Like JavaScript in a browser that shares a thread with the UI, prolonged JavaScript execution can cause the RENDERING and response of the UI to be interrupted. In Node, a long period of CPU usage will also cause subsequent asynchronous I/ OS to fail to be called, and the callback function of completed asynchronous I/O will not be executed in a timely manner.

3. The above mentioned single thread is bad for computing, can not use multi-core CPU, isn’t there a solution?

There is.

Node takes the same approach as Web Workers to solve the problem of single-thread computations: child_process.

The presence of child processes means that Node can handle the robustness and inability of single threads to take advantage of multi-core cpus in stride. By distributing computations to child processes, you can break down a large number of computations and then pass the results through inter-process event messages, which keeps the application model simple and low dependency.

4. Can you talk about node usage scenarios

Node is mostly I/O intensive and CPU intensive.

I/O intensive

Over the course of the Node rollout, there have been countless times when people have asked what the scenarios for Node are. If all scripting languages are judged in one place, Node’s ability to handle I/O from a single-threaded perspective is a thumbs up. In general, there is little disagreement that Node excels at I/O intensive scenarios. Node is network-oriented and good at parallel I/O, which can efficiently organize more hardware resources to provide better services.

The I/O intensive advantage is that Node takes advantage of the processing power of the event loop, rather than starting each thread to service each request, which consumes very little resource.

cpu-intensive

On the other hand, in cpu-intensive application scenarios, can Node do the job? In fact, V8 is quite efficient. In terms of execution efficiency alone, V8’s execution efficiency is indisputable.

CPU intensive applications pose a major challenge to Node: Due to single-threaded JavaScript, long running computations (such as large loops) will result in CPU time slices that cannot be released and subsequent I/ OS cannot be initiated. However, the large operation task can be properly adjusted and decomposed into several small tasks, so that the operation can be released timely without blocking the initiation of I/O calls. In this way, the benefits of parallel asynchronous I/O can be simultaneously enjoyed, and the CPU can be fully utilized.

CPU density is not terrible, how to properly schedule is the trick.

The last

This article was first published on the public account “Front-end Sunshine”, welcome to exchange technology with your friends