Translation] Bigpipe: High-performance "pipelining Technology" Web page

Original address: http://www.facebook.com/note.php?note_id=389414033919
Address: http://isd.tencent.com/?p=2419
Author: Changhao

Facebook's website speed is one of the most critical corporate tasks. In 2009, we successfully achieved a twice-fold increase in the speed of our Facebook website. And it is the key innovations of our engineering team that make it possible. In this article, I will introduce you to one of our secret weapons, the great underlying technology we call Bigpipe.

Bigpipe is a redesigned basic Dynamic Web Services system. The general idea is to break down the pages into small chunks called pagelets, and then build pipelines through Web servers and browsers and manage their operations at different stages. This is similar to most modern microprocessors in the pipeline execution process: Multiple command pipelines through different processor execution unit to achieve the best performance. Although Bigpipe is a redesign of the existing service network infrastructure, it does not need to change existing Web browsers or servers, and it is fully implemented using PHP and JavaScript.

Motivation

To get a better understanding of bigpipe, we need to look at the existing Dynamic Web services system, which dates back to the beginning of the World Wide Web, but has not changed much compared to the beginning. Modern web sites are much higher than the dynamic effects of the 10 and interactive, but the traditional Web services system has long been unable to keep up with the current Internet speed requirements. In traditional mode, the lifecycle of a user request is as follows:

1. The browser sends an HTTP request to the Web server.
2. The Web server resolves the request, then reads the data storage layer, draws an HTML file, and sends it to the client with an HTTP response.
3. HTTP responses are transmitted over the Internet to browsers.
4. The browser parses the Web server's response, builds a DOM tree using HTML files, and downloads the referenced CSS and JavaScript files.
5. After the CSS resource is downloaded, the browser resolves them and applies them to the DOM tree.
6. After downloading JavaScript resources, browsers parse and execute them.

Traditional models are very inefficient in modern web sites because many systems operate in a sequence that cannot overlap each other. Some of the constraints such as delay-loaded JavaScript, parallel downloads and other optimization techniques have been widely adopted by the network community to overcome. However, these optimizations rarely involve bottlenecks in the order of execution of Web servers and browsers. When the Web server is busy generating a page, the browser is idle, wasting its cycles doing nothing. When the Web server completes the build page and sends it to the browser, the browser becomes a performance bottleneck and the Web server does not help it. Overlapping Web server generation time and browser rendering time, we can not only reduce the final time delay, but also enable the page to show the user's visible area earlier to the user, thereby greatly reducing the user's perception of latency.

Web server generation times and browser rendering time overlap, is particularly useful, such as Facebook's content-rich web site. A typical Facebook page contains many different sources of data: Buddy list, Buddy news, ads, etc. In the traditional Web page rendering mode, users will have to wait until these query data are returned and generate the final file, and then send it to the user's computer. Any query delay slows the generation of the entire final file.

How Bigpipe Works

To take advantage of the parallelism between the Web server and the browser, Bigpipe first decomposes the page into multiple callable pagelets. Just as the pipelined microprocessor divides the lifecycle of an instruction into several stages, such as "Fetch instruction", "instruction Decoding", "Execution", "writeback register", and so on, the Bigpipe page generation process is divided into the following stages:

1. Request Resolution: HTTP requests for Web server resolution and integrity checking.
2. Data acquisition: The Web server obtains data from the storage tier.
3. Markup generation: HTML markup for the response generated by the Web server.
4. Network Transmission: The response is transferred from the Web server to the browser.
5. css Download: Browser download Web page CSS requirements.
6. DOM tree structure and CSS styles: A browser-constructed DOM document tree, and then apply its CSS rules.
7. JavaScript Downloads: Browsers Download the resources that JavaScript references in the Web page.
8. JavaScript execution: The browser's Web page executes JavaScript code.

The first three phases are executed by the Web server, and the last four phases are performed by the browser. Each pagelet must pass through all these stage orders, but bigpipe several pagelets simultaneously at different stages.

(Pagelets of Facebook's homepage, each rectangle corresponds to a pagelet.) ）

The above picture uses the Facebook homepage as an example to illustrate how to break a Web page into pagelets. The home page includes several pagelets: "Author Pagelet", "Navigation Pagelet", "News Pagelet", "Request Box Pagelet", "Advertisement Pagelet", "Friend Recommendation" and "contact" and so on they are independent of each other. When "Navigation Pagelet" is displayed to the user, "news Pagelet" can still be generated on the server.

In Bigpipe, the lifecycle of a user request is this: sending an HTTP request to a Web server in the browser. Upon receiving the HTTP request and doing some comprehensive checking on it, the Web server immediately sends back an open HTML file that includes an HTML tag and a label's start tag. The tag includes a bigpipe JavaScript library to resolve replies received after Pagelet. In the tab, there is a template that specifies the logical structure of the page and the pagelets placeholder. For example:

After rendering the first response to the client, the Web server continues one after another to generate pagelets as soon as a pagelet is generated, he will immediately flush the client in a JSON-encoded object, including all the Css,javascript pagelet, its HTML content , as well as the resources required for some metadata. For example:

The Bigpipe JavaScript Library will first download its CSS resources when the client receives the Pagelet from the "Onpageletarrive", and after the CSS resource is downloaded, Bigpipe will display its innerhtml in Pagelet markup HTML. Multiple pagelets CSS can be downloaded at the same time, they can confirm the display order according to their respective CSS download completion. In Bigpipe, JavaScript resources have a lower priority than CSS and page content. Therefore, Bigpipe does not download JavaScript in any pagelet until all pagelets are displayed. Then, all pagelets JavaScript are downloaded asynchronously. The last Pagelet JavaScript initialization code determines the order of execution based on their respective download completion.

The end result of this highly parallel system is that the different stages of execution of multiple PAGELETSR are simultaneous. For example, the browser could be downloading three pagelets CSS resources while another pagelet content was being displayed, while the server was also generating new pagelet. From the user's point of view, the page is gradually rendered. The first page content will be displayed faster, which greatly reduces the user's perception of page latency. If you want to see the difference with your own eyes, you can try the following links: traditional mode and bigpipe. The first link is the traditional mode single mode display page. The second link is the Bigpipe Piping mode page. If your browser version is older, the network speed is also very slow, browser cache is not good, which two pages between the time difference will be more obvious.

Performance Test Results

The following figure is a comparison of traditional and bigpipe performance data, which is the perceived latency of 75% of users on the most important content of a page (for example, news is considered the most important content on the Facebook page). The way to collect data is to load the Facebook home page 50 times and disable the browser cache. The figure shows that bigpipe reduces the latency that users experience in most browsers by half.

(Facebook homepage delay time comparison)

It is worth mentioning that Bigpipe is inspired by the assembly line of microprocessors. However, there are some differences between their pipelining processes. For example, although most stages bigpipe can only operate once pagelet, sometimes multiple pagelets css and JavaScript downloads can work simultaneously, similar to superscalar microprocessors. Bigpipe Another important difference is that we implement the "barrier" concept introduced from parallel programming, all pagelets to complete a specific phase, such as multiple pagelet display areas, which can be further JavaScript download and execution.

At Facebook, we encourage creative thinking. We are constantly trying to innovate technology to make our site faster.

Author Changhao, currently a research scientist at Facebook, is working on a variety of innovations that make the site faster.

(translator also found a few articles on Bigpipe, if interested you can understand: Facebook innovation bigpipe: Optimize the page load time, the name station Technical Analysis-facebook peculiar page loading technology, Facebook Bigpipe Technical Analysis, Facebooks bigpipe in Java, Open bigpipe JavaScript implementation, Tutorial: Implementing Facebook ' s bigpipe Using asp.net MVC, bigpipe do in Node.js)

Source: http://isd.tencent.com/?p=2419