This article is shared by Tiv, the content front end team of Tao Department

antecedents

Before getting started, I’ll talk about a detailed business scenario and the performance issues it faces

Business characteristics

The business itself has three major features:

• It’s huge, billions of dollars, and it’s growing like crazy every day;
• Traffic is large, in order to support such a large business, need a lot of server costs;
• The content data is very static, the page reference is as follows, except for the data marked in blue, other data will rarely change;

So what does the loading and rendering process look like for such a page?

Summarize problem

Several issues can be seen from the above process:

• The first screen rendering relies on multiple requests, resulting in poor performance of the first screen rendering, especially on low-end machines
• The server is under a lot of pressure. Every request needs to be sent to the server, which brings a lot of pressure to the server
• The content is rendered repeatedly, so that everyone sees the same content, but the rendering results are not shared

Bold thinking

At this time, we need to combine the characteristics of the business itself to make some bold thinking:

Pre-render during development

The first thought was to pre-render and store the content during development, but this was quickly adopted for two main reasons:

• Too large internal capacity: the amount of content is too large, and a content will show different styles in different scenes (hundreds). All static storage CDN resources are seriously wasted
• Update costs are high: content will be modified by experts, or some marginal content needs to be removed as soon as possible

Render results statically on demand

Since most of the data is static, why not static data and rendered code when accessed by the user, without the need for renderToHTML? , as shown in the figure below

RenderToHTMLString is a simple sequence sequence sequence sequence (SSR) renderToHTMLString, and the result is cached. If the request accesses the same content, the cached result can be returned directly.

• Reduce repeated rendering and improve first screen performance
• Reduce stress on interface services
• Based on access storage, avoid resource waste

But it also brings other problems:

• The distance between the SSR application server and the user prolongs the white screen
• The pressure on SSR itself increases, because it means that every user request goes through SSR (although it can be cached).
• The problem of cache data storage, where to store, memory certainly does not meet the demand, because at the beginning of the talk about the internal capacity is very large, at this time to rely on some other fast storage cloud services, it is very complicated

At this time, we were thinking that it would be good if we could put the rendering results or the rendering process on CDN. Since CDN nodes are more numerous and are widely deployed worldwide, we tried to store the SSR rendering results on CDN, but some other problems followed:

• Now CDN is a configuration effective system, as shown in the figure below. As we mentioned above, the traffic of graphic details is particularly large, which means that all kinds of abnormal situations should be considered. For example, the risk of SSR server downtime, we must also have a degradation plan to ensure that users are not affected

• For two special scenarios, the cache needs to be updated in time: the content of marginal ball should be offline in time, and the cache should be updated in batches for page code updates. At present, the configuration items of CDN cannot solve these problems

At this time, we happened to know that CDN is promoting a kind of edge computing capability (EdgeRoutine, which will be briefly introduced below). The simple understanding is that you can add your custom script before the CDN request returns the result, and can access the CDN data. That means we can control the content returned by CDN request or the HTTP state, which seems to be able to basically solve the two problems I mentioned above. Therefore, according to the current technical capability and our needs, we have reformed the request link:

The logic of the degradation and cache cleanup is not drawn, because that is to address the safety of production issues, and I mainly want to emphasize the performance improvements that solution adjustments bring.

Therefore, it can be seen from the figure above that a normal request will first be requested to CDN, and if CDN is found not in the cache, it will be back to the SSR server. In this way, only one network request is required for the first screen, which effectively improves the performance of the first screen and reduces the server pressure. Careful you’ll find page after the first screen also made a request to the action of dynamic data, because there is a high real-time demand of data need to show to the user, but does not affect users browse, while other content is not how can update but there will also be updated, so we will do in the browser cache time and contents of the latest update time of contrast, If the inconsistency is found, the cache will be updated actively. In this way, the performance is ensured and the cache expiration is avoided

earnings

By doing the above solutions we have achieved great gains in performance, business indicators, and server stress

Significantly improved performance, low-end first screen within 1S

Business indicators improved significantly

Reduce server pressure by 80%

Edge computing ER

On edge, you can reference: developer.aliyun.com/article/757…

This article has posted a few key diagrams for your reference:

A brief summary is that we can perform some logical calculations before the CDN returns the results, and this part of the code is compatible with ES6 specifications, and can communicate with external services through HTTP, so as to effectively control the performance of the CDN returns

Advantages – Sharing

Here I would like to focus on the sharing advantages of edge computing. For edge computing, it can not only process some logical calculations, but also store the results of calculation. The storage capacity is Swift Open API, realizing KV storage of data, which means that the storage space can be very large. Here you may feel abstract, you can see the following figure, which refers to our normal network request. The user’s mobile phone is directly connected to the data server and the page CDN, which means that everyone has to go through the logic of page loading, data loading, page rendering and so on. The following refers to the CDN ER does a layer of proxy, which means that the user’s mobile phone links to the CDN, and the CDN is responsible for communication with the data server and the page CDN. So what’s the benefit of that? It means that we can store data like content details or render results directly on the CDN without worrying about the performance impact of storing too much content. It’s like a bunch of people sharing a cell phone, and you pass it on to the next person to refresh the same content

Advantage – computing power

Since we can write ES6 code on the ER node of CDN and request data, this means that we can perform a lot of logic on ER. Here I will sort out some common ones:

Based on these capabilities, what other suitable scenes can we support? So we conducted a survey on Amoy scenes

Scene investigation

There is a unified idea in the overall survey, that is, to find high-flow scenes suitable for static, that is, whether the page has data or rendering results that can be cached, for which we have compiled a simple table:

Here are some simple instructions:

• The end type of page generally has a content body, and these subject data is not thousands of people, such as the above mentioned, content details, product details, personal home page, comment list, comment details
• To build class business, configuration information needs to be loaded asynchronously at present, and modules also need to be loaded asynchronously. Can these configured things be directly output together with the page
• List types of pages, as well as a list of everyone to see, but the list to update, but this update is not real in real time, generally to carry more traffic, is a quasi real-time data, such as minutes update, class hour update, updated once a day, even that in the period of validity can be actually list rendering the results of the cached data or lists

To summarize the standard page request process:

For example, with the help of CDN, Tair and OSS, if we can make the process of statics more simple and universal, such as storing data or page rendering results directly in CDN, the next request can directly reuse the rendering results. Is it possible to change into the following pattern:

There are two principles:

• Reduce the number of HTTP requests, as far as possible a request to the first screen;
• Reuse of rendering results: put the rendering process on ER and cache it down, directly reuse the rendering results, or for our commonly used skeleton diagram scheme, whether it can be changed into the rendering results of static data;

Scene standardization

Finally, combining the capabilities of ER and our business scenarios, we abstract them into the following four types:

• SSR statics: it means to cache SSR results on CDN quickly
• ESR(Edge Side Render) : As the name implies, the process of renderToHTMLString is placed on the ER node and the Render result is cached
• Data pre-request: it means that the logic of requesting data after rendering is pre-placed on ER, and the result of the request is merged and returned to the browser
• The location. Href is much faster at the front end than it used to be
• Include: fragment injection, which can inject any text content into any file type, a more general solution

After our test and practice, some performance report for the first three output can also be Shared with everybody, although not comprehensive, but telling, as a result of the test page scene is different, so each other (data preloading, ESR, SSR static) there is no need to compare, not using the following indicators is relatively TESI ability of comparison

Standardized access

Although ER has so many advantages, access costs are still relatively large. For example, we need to pay attention to the limitations of ER container itself, debugging costs, cloud resource application costs, etc., so we need to provide a standard access method.

ESI is a small markup language that makes the web dynamic at the edge. ESI is designed to solve the scaling problem of the Web infrastructure. It is an application scheme of edge computing

The principle is shown as follows:

In fact, through the way of label injection, dynamic and static content mixed output, more in line with our appeal, and its syntax is also more rich

But the problem is ESI is an XML standard, ali has many page resources type is not HTML, such as WEEx, small programs, etc., they load pages are not HTML, and we need to meet the access of standardized scenarios. Therefore, we need to carry out transformation on the basis of ESI — TESI (Taobao Edge Side Includes). The most suitable one is the best one

How about the basic code form? Let’s take data preloading as an example. TESI tag appears in H5 below (mouse selected part).

The TESI tag describes the information of an HTTP interface and is configured with its cache duration S-maxage. ER will parse the tag and initiate a request on ER and cache the requested data according to the value configured by S-MAXage. This means that the next request will be sent to the same node. It returns the cached result directly

Render the result as follows:

In the case of data preloading, the HTML is rendered as a script tag that stores a global variable that is easy to fetch at runtime.

In fact, TESI tag can not only be used in HTML, JS can appear TESI tag, as follows:

After the rendering

Its basic rendering principle is as follows, relatively simple, here do not do redundant:

There are several other types of labels as follows:

Stable relegation

The whole process of ER execution will encounter various problems, and even ER is at risk of failure, so it is necessary to have a plan for stable degradation to ensure that users are not affected. Therefore, we will point the CDN source site to the source site of the page CDN, so that in case of ER parsing problems, the page before parsing can be directly returned to the browser

Cache management

storage

ER provides two kinds of Cache: memory Cache (hereinafter referred to as Cache) and Swift KV Cache (hereinafter referred to as KV). These two modes have differences in access speed, volume size and QPS, which can be summarized as follows:

The storage side effect refers to the impact of the storage size on ER performance. If the storage size is close to the memory size in the cache, ER performance will be affected first or ER container restart will occur

Considering the above two comparison results, it can be seen that they have their own strengths and weaknesses, but appropriate mode is the best for appropriate scenes. For this purpose, we designed the second-level cache mode, with the first-level cache stored in memory and the second-level cache stored in KV, mainly achieving the following three key logic:

• Dynamically calculated heat content is pushed into level 1 cache
• LRU (most recently unused algorithm) mode is used to achieve level 1 cache and level 2 cache data push, make full use of cache space
• Each label sets a specified cache space to avoid uneven cache allocation and mutual influence

Cache invalidation

Caching the content of the need to have the ability to quickly remove, because the data will be update, bundle pages will be updated, especially in an emergency, such as online problem emergency repair, need to be able to realize the cache to clear in time, so I need some strategy to meet the demand, the overall clear logic will depend on the request, according to the identity of the tag information is clear

Access to the process

In order to meet the requirements of system stability and safe production, the production process of TESI label needs to be controlled, so we need to provide a TESI operation and maintenance system to mainly meet the following requirements:

The operation and maintenance system is used as follows:

The operation and maintenance system is mainly to generate a usable TESI label, and we will make use of the DEF release system when the release takes effect. In this way, we do not need to repeat the construction of safety production related capacity, and the basic process is as follows:

The appendix

Noun introduction:

• ER: EdgeRoutine
• ESR: Edge Side Render
• SSR: Server Side Render
• ESI: Edge Side Includes
• TESI: Taobao Edge Side Includes
• DEF: Ali front-end publishing system
• Swift: Aliyun CDN file storage

Brief introduction of several common service types:

The basic configuration information and execution process are as follows:

The last

Is a timeless topic, if you are interested in the edge of computing, welcome to join our common construction, if you are interested in our business, also welcome you to join, understanding of business: zhuanlan.zhihu.com/p/128956855

Resume: [email protected]

Topic Remarks: Front-end – Company – Name