LinkedIn replaces rails with node: Reduces 27 server speeds by 20 times times

Ryan http://www.aliyun.com/zixun/aggregation/13830.html ">paul wrote an in-depth look at the design of the mobile side of LinkedIn, where we saw: 23% of mobile users; focus on simplicity , ease of use and reliability; 30% native code, 70% uses HTML, embedded lightweight HTTP service, single client application link cloud server, back-end service from rails to node.js.

Lan Yique, an engineer who worked in LinkedIn, added: "Mobility has led to the use of data centers." Run on a single-threaded rails server (each request lowers overall performance), and using mongrel will waste a lot of memory. This explains why any way without blocking will win the favor.

The advantages of Node.js are:

Obviously, there are a lot of problems intertwined. We need to rewrite the code to change the distributed logic between the server and the client, in order to optimize the number of places we need to argue. But it is certain that LinkedIn's choice of Node.js has been a great success.

In the comments section of the article, see some interesting analysis, I particularly like Oluseyi's comments:

Inevitably we want to refactor and rewrite, we actively use caching, store client templates (and inevitably update data from the server). This means that once the timestamp requires an update of the cache, the application needs to update the data from the server consistency filter instead of opening and closing several connections. We want to build a long life connection to transmit data. (Again, the original execution will return the HTML code, which means that links, including the URI address of the image, will point to the server.) Also, because Web browsing will create and destroy navigation, these images do not have a valid cache. ）

In the way of long life link, in the traditional MVC ("model-view-controller" abbreviation, Chinese translation is "mode-view-controller". Web applications no longer have the concept of "view." The end result is that the server-side controllers will aggregate all the necessary data, but the data will not be output directly, but rather by outputting the binary object and extracting all the relevant data by the client unpacking.

I've noticed that you're concerned about the overuse of MVC, which is suitable for applications only in specific Web application-related environments. The user's Web side (labeled output, including external URLs, etc.) will extract the data from the unpacking and cache data. (CSDN compilation/Bao)

(Responsible editor: The good of the Legacy)