Web Performance Upgrade: The era of total station cache has not been keeping up with demand

　　principle : Static and dynamic separation, hierarchical cache, active failure.

In WEB development, interfaces are divided into the following categories:

A purely static page. Kill me. The page is not modified. For a long period of time, basically will not be modified. For example: About us.

Pure dynamic page. Real-time, personalized requirements are relatively high. The page varies greatly, or every user sees something different, such as a circle of friends.

Short-time static pages. It doesn't change for a certain amount of time, or it doesn't need to be updated in real time. For example: articles, news.

Dynamic Combination page. This page has both dynamic and static content. is also the most practical application.

For the above types of pages, you can do different caching scenarios. You, the gods, should adjust the caching scheme flexibly according to the situation of their own business. The following content can be used as a reference.

Template rendering

The rapid development of the template engine, the front-end rendering brings vitality. Mustache, jade, HBS Flexible template syntax makes page development easier and more efficient.

Htmldom = = Veiwengine.render (template, data);

The browser only knows the DOM structure of the string, which is often called the HTML5 format. For the front-end to render the DOM, or the back-end rendering problem, there is no discussion, the back-end rendering will be more appropriate for the performance and experience of the front-end. For the same page, will each request produce a render? Rendering is always calculated, so much wasted server performance Ah! That's true, unless you're using a cache.

　　Scenario for page Caching

1. Pure static page

Put CDN directly. The amount of access to a purely static page is generally not very large, and the program's direct response is also possible.

2. Pure dynamic page

All say is a dynamic page, then do not do page cache. Consider doing a data cache, or Redis, DB cache.

3. Short-time Static page

1. Server-side file caching

Request-to-process interface-to-template rendering---> Store file---> response file

Cache dynamic pages, you can also save the generated files to the CDN, and then let the CDN respond to the request. If your request requires some validation, store the file on the server and the Business Server responds to the request. One of the benefits of a file is: stream. For example: Filereadstream.pipe (Responsestream). In response, you do not need to load the contents of the file into memory, but instead respond directly to the stream. But there are many drawbacks, file storage, there will be concurrent read and write deadlock problem.

There is also a problem with distributed systems. Maybe you have a, B, C three servers. A server generates a file and needs to be synchronized to B and C in real time. Of course, you can also have a, B, C mount the same disk. The question is again, do you want to back up this file?

2. Redis Cache

Request-to-interface interface---> Template rendering----response DOM

Consider the URL of the request as a key, render the data in the template as a value, and then store the data in Redis according to the cache rules.

This small-cost cache is practiced in our system, and indeed dramatically improves the response time and QPS of the system, most of the page requests are read from Redis, then returned, single-machine tested for extreme performance, 14k QPS. A brief description. We call it static staticize.

Start request

Request validation, filter, etc.

Querying Cache Redis

If there is a cache, the direct response

No caching, querying data, re-rendering, storing to Redis.

Response

If you need to update the cache, just delete the corresponding Redis value

4. Combination of static and dynamic pages

This kind of page is more common in reality. Principle: Static page caching, dynamic partial asynchronous request.

The static part is also rendered by the template, and the browser gets the static page from the CDN or back-end cache. The time the page responds and the browser's rendering will directly affect the user experience. Dynamically updated sections are typically in some detail, such as the login status of the page. For all users, the page I see is only partially inconsistent with the user's avatar. If the system generates a static page for each user the cost is too high and completely unnecessary.

This page becomes: page = = short-time static page + local dynamic page.

"User state information" This special dynamic content, also need to use the local cache mechanism. When the user switches the page, each page needs to load the user information dynamically, so it is our practice to store the information to localstorage the first time it is requested, and then set the expiration time. When exiting, take the initiative to clean up the localstorage.

For example: personalized, personal recommendation of the individual plate can be made into the form of local dynamic pages.

5. Data caching

The above scenario also applies to asynchronous requests.

For CDN or other caches, the cache does not know whether your content is DOM or JSON or other formats. It just helps you store the data. You can also store data interfaces, local DOM structures (not full HTML formats) in a CDN or Redis. For example: The configuration information of the page, or the DOM structure requested from the relevant recommender system.

　　Cache Updates

There are generally active invalidation and auto-fail caching mechanisms.

Caches such as CDN and Redis can set the cache time according to the rules. After the cache expires, the new data is retrieved again. Active updates are typically implemented in the API invocation mode. such as deleting a key, or calling the CDN interface for a delete operation

Cache penetration

Typically, the cache is generated on the first request, and if the server does not have a cache, and then a high concurrent request occurs at the same time, the request will go directly to the Business logic section, which is likely to cause the system to hang up directly.

Workaround:

Create the cache proactively. The cache is created by the system timer.

Set the flag bit when requested. The first request arrives, identifies the URL that is creating the cache, and the other requests enter the wait queue.

Full-site CDN acceleration

CDN dynamic acceleration as shown:

For example, my site has the following interfaces and pages:

http://www.localhost.com/

Http://www.localhost.com/api/user/1

Http://www.localhost.com/post/hello-world

Therefore, 1, 3 pages will be put to the cdn,2 directly to the source station request. How do you do it?

Configure the autonomous source station in the CDN. means that when requesting a CDN address, the CDN will go to the source station to request the data and then cache it to the CDN node.

Set Cache Rules

/cache 1 Minutes

/post/* Cache for 1 years

/api/do not set the cache

CNAME www.localhost.com to the space domain name provided by the CDN

　　Multi-platform Mulit Origin

A URL may have different returns and representations on different platforms.

Product ideas are perfect, a button on different platforms will have different display status. The actual situation is very complex, in our system, appeared a page appeared in seven platforms, each platform display effect will be inconsistent. Either the template rendering, or the JS processing button state, and so on are very complex, or the PC and mobile pages show style and structure differences. If you want to put this page in the cache, it's more complicated.

Generate a cache for each platform? OK!

Platform recognition comes from useragent, different browsers or apps, all with different useragent. Different sources we call origin. The Origin + URL can generate a unique key to identify a unique cache. The cache is not limited to Redis and file caching.

CDN Identify the source to read the different files, you need to do some development work in the CDN. Upyun, seven cattle side is not supported for the time being. BAT is the perfect way for a large company to maintain its own CDN.

Another way of thinking:

1 items, two domain names, 2 dynamic CDN. PC and mobile page separation, interface sharing.

For example: Configure two domain names for the same project: Www.localhost.com and M.www.localhost.com, and set up a dynamic CDN for each of the two domains.

A project provides two domain name services, such as: Indexcontroller.main processing request/homepage, mobile and PC side of the request path is

Http://m.www.localhost.com/homepage

Http://www.localhost.com/homepage

The main action renders different pages according to the URL of the request source. Different domain name pages are also cached by different dynamic CDN.

For the/api/xxxx interface, naturally do not need to do PC and mobile or other platform of the distinction, an action can be solved. This avoids the problem of maintaining two sets of systems.

　　Conclusion

Above, the whole station cache is basically complete.

Do not go out of thin air to pull up the QPS or mess with the cache, according to your business and the actual situation to treat. The most important thing to remember: keep it simple and use it on demand.

Web Performance Upgrade: The era of total station cache has not been keeping up with demand