Web Performance Improvement record: the whole site cache era is no longer up to meet requirements, and performance improvement

Web Performance Improvement record: the whole site cache era is no longer up to meet requirements, and performance improvement

　　Principles: Static and Dynamic separation, Hierarchical Cache, active failure.

In Web development, interfaces are classified into the following types:

Pure static page. Pages that I will not modify when I am killed. It will not be modified for a long time. For example, about us.

Pure dynamic page. Real-time, high Personalized Requirements. The page changes a lot, or each user sees something different, such as a circle of friends.

Short-term static page. It will not change within a certain period of time, or it will tolerate the absence of real-time updates. For example, articles and news.

Dynamic/static page. This page contains both dynamic and static content. It is also the most practical application.

For the above types of pages, you can do different cache solutions. You should flexibly adjust the cache scheme based on your business needs. The following content can be used as a reference.

Template Rendering

The rapid development of the template engine brings vitality to front-end rendering. The flexible template syntax of Mustache, jade, and Harvard makes page development more efficient and efficient.

HtmlDOM = VeiwEngine. render (template, data );

The browser only recognizes the strings of the DOM structure, that is, the HTML5 format. We do not need to discuss the problem of DOM rendering on the front end or backend rendering. In order to improve the performance and experience of the front end, backend rendering is more suitable. For the same page, will each request produce a rendering? Rendering always requires computing. This wastes a lot of server performance! This is true, unless you use the cache.

　　Page cache Solution

1. Pure Static Page

Direct release of CDN. The volume of access to a pure static page is generally not very large, and the program can respond directly.

2. Pure dynamic page

If it is a dynamic page, do not cache the page. You can consider data caching, or redis or DB caching.

3. Short-term Static Page

1. server-side File Cache

Request --> processing interface --> template rendering ---> storage file ---> response File

Cache dynamic pages. You can also save the generated files to CDN and then let CDN respond to the request. If your request requires some verification, the file is stored on the server and the Business server responds to the request. Another benefit of a file is stream. For example, FileReadStream. pipe (ResponseStream ). In response, you do not need to load the file content to the memory, but directly respond in stream mode. But there are also many drawbacks, such as file storage, and concurrent read/write deadlocks.

Another problem is the distributed system. You may have three servers, A, B, and C. Server A generates A file and needs to be synchronized to server B and server C in real time. Of course, you can also mount A, B, and C to the same disk. The problem is, do you want to back up this file?

2. Redis Cache

Request --> interface ---> template rendering --> store data --> response DOM

Use the requested url as the key, use the data rendered by the template as the value, and store the data in redis according to the cache rules.

This low-cost cache has practices in our system, which indeed greatly improves the system response time and QPS. Most of the page requests read data from redis and then return data, the maximum performance of a single machine is tested, and the QPS is 14 kb. A brief description. We call it static staticize.

Start request

Request validation, filter, etc.

Querying cache redis

If there is a cache, the system directly responds.

No cache, data query, re-rendering, and storage to redis.

Response

To update the cache, you only need to delete the corresponding redis value.

4. Dynamic/static page

This type of page is more common in actual situations. Principle: Static Page cache, dynamic part of asynchronous requests.

The static part is also rendered by the template. the browser obtains the static page from the CDN or the background cache. The page response time and browser rendering will directly affect the user experience. The dynamic update part is generally in some details, such as the logon status of the page. For all users, only the user profile pictures on this page will be inconsistent. If the system generates a static page for each user, the cost is too high and unnecessary.

This page becomes: page = short-term Static Page + local dynamic page.

The special dynamic content "user status information" also needs a local cache mechanism. When users switch pages, each page needs to dynamically load user information. Therefore, we store the information to localStorage and set the expiration time when we first request this information. When you exit, actively clean up localStorage.

For example, personalized and personal recommendations can be made into local dynamic pages.

5. Data Cache

The preceding scheme also applies to asynchronous requests.

For CDN or other caches, the cache does not know whether the stored content is DOM, JSON, or other formats. It only helps you store data. You can also store data interfaces and local DOM structures (in incomplete html format) in CDN or redis. For example, the page configuration information or the dom structure requested by the related recommendation system.

　　Cache update

Generally, there will be active invalidation and automatic invalidation cache mechanisms.

Cache time can be set based on rules for CDN, redis, and other caches. After the cache expires, new data is retrieved again. Active updates are generally implemented using API calls. For example, deleting a key or calling the CDN Interface

Cache penetration

Generally, the cache is generated during the first request. If the server does not have a cache and a high-concurrency request occurs at the same time, the request will directly reach the business logic section, the system may be suspended directly.

Solution:

Actively create cache. Cache is created regularly by the system.

Set a flag in the request. The first request arrives, marking that the url is creating a cache, and other requests enter the waiting queue.

Full-site CDN Acceleration

Shows CDN dynamic acceleration:

For example, my website 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, pages 1 and 3 are placed on CDN, and 2 are directly requested from the origin site. How can this problem be achieved?

Configure the Origin Site on CDN. This means that when a CDN address is requested, CDN will go to the origin site to request data and then cache it to the CDN node.

Set cache rules

/Cache for 1 minute

/Post/* cache for 1 year

/Api/do not set Cache

Cname www.localhost.com: The domain name provided by CDN.

　　Multi-platform muw.origin

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

The idea of a product is perfect, and a button is displayed on different platforms in different States. The actual situation is very complicated. In our system, a page appears on seven platforms, and the display effects of each platform are different. Whether it is template rendering or js processing button status, it is very complicated, or the pc and mobile pages show style and structure differences. It is even more complicated to put this page in the cache.

Is a cache generated for each platform? Yes!

The platform's identification comes from UserAgent. Different browsers or apps have different useragents. Different sources are called Origin. The Origin + url generates a unique key to identify the unique cache. Cache is not limited to redis and file cache.

When CDN identifies the source to read different files, it needs some development work on the CDN side. Upyun and qiniu are currently not supported. The CDN maintained by BAT can be perfectly implemented by large companies.

Another idea:

One project, two domain names, and two dynamic CDN. Page separation between PC and mobile terminals and interface sharing.

For example, configure two domain names for the same project: www.localhost.com and m.www.localhost.com, and set a dynamic CDN for each of these two domain names.

A project provides two domain name services, for example, IndexController. main processes the request/homepage.

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

Http://www.localhost.com/homepage

The main action renders different pages based on the request source url. Different domain name pages are cached by different dynamic CDN.

For/api/xxxx interfaces, you do not need to differentiate between PCs, mobile terminals, or other platforms. An action can solve this problem. This avoids the maintenance of two sets of systems.

　　Conclusion

Above, the full-site cache is basically complete.

Do not pull high QPS out of thin air or use the cache indiscriminately, depending on your business and actual situation. The most important thing is to keep in mind: Keep it simple and use it on demand.