Vernacular bigpipe [Reproduced]

Bigpipe refers to the technology developed by Facebook to improve the client response speed. Essentially, it is not a new thing. The principle is equivalent to the flush the buffer early proposed by Yahoo in the best practices for speeding up your web site. However, the implementation of bigpipe is more flexible, so it is necessary to know one or two.

The experience we usually experience when browsing a webpage is usually serialized: the browser initiates a request, and the server renders the page after receiving the request. During this period, the browser has no choice but to wait. The Demo code is as follows:

<?phpsleep(1);$header = 'header';sleep(1);$content = 'content';sleep(1);$footer = 'footer';?>
Note: use sleep in the code to simulate time-consuming operations on the server.
What if we change serial to parallel? Every time the server generates new content and sends it to the browser immediately, the browser renders it immediately without waiting until it receives all the data for further processing. There is no doubt that this will improve the user experience. The Demo code is as follows:
Note that the Code only runs in the Apache + mod PHP environment. The old version of Apache may need to disable gzip.
Note: Some browsers must receive content of a certain length before rendering starts, so str_pad is used in the code.
The Code uses ob_flush and flush to refresh the page in blocks and cache it to the browser. If you use firebug to view the response header, you will find: Transfer-encoding = chunked, in this way, the browser can implement multipart rendering.
Bigpipe goes further on this basis. The Demo code is as follows:
When using bigpipe, refresh the layout (layout) first, and then refresh the corresponding JavaScript code by block (header, content, footer) to fill in the page content.
Bigpipe uses JavaScript to render a page because it is not bound by the block position when rendering the page. If our server supports multithreading, it can process multiple pieces of content at the same time, the server can refresh the content to the browser after processing it. Even if multithreading is not supported, the server can render the content in order of importance, without sticking to the physical order of HTML code. In addition, pay attention to the differences between bigpipe and Ajax. For a page that is divided into several blocks, if Ajax is used, each block needs to send an HTTP request separately, if bigpipe is used, no matter how many blocks there are, there is only one HTTP request. Therefore, Ajax may cause several times more pressure on the server than bigpipe.
Note: bigpipe is not conducive to Seo. You can use the user agent to determine whether the request is a person or a search engine. If the request is a person, the bigpipe rendering mode is applied. If the request is a search engine, then the traditional rendering mode is applied.
Supplement: the code in the nginx + PhP FastCGI environment will be invalid, which is caused by cache. In the nginx FastCGI environment, if the data is smaller than fastcgi_buffers, it will be cached in the memory. Otherwise, if the data is smaller than fastcgi_max_temp_file_size, it will be cached on the hard disk. Because flush is a function effective in the Apache environment and is not applicable to the nginx environment, the only way out is to disable the cache. experiment shows that even fastcgi_buffers and fastcgi_max_temp_file_size are disabled, so far, nginx + PhP fastcg cannot implement bigpipe. the feasible method is to implement bigpipe through Apache + mod PHP, while nginx is placed on the proxy server role, use proxy_buffering to disable the proxy cache.
See Ajax, cache, and pipeline for Facebook websites (PDF ).
Address: http://huoding.com/2011/06/26/88