Performance Optimization - Cache

overview

What is caching? Where can I see it? Why do it?

1. Baidu Encyclopedia can explain, including various directions (cache)
2. The most common is the location where this article is currently seen - the browser, open F12,
   
   Chinese characters are easy to find; including hard disks, servers, etc. are its containers,
3. The setting of the cache is one of the important factors for the high performance of all modern computer systems.

This article briefly talks about browser caching , as a note

In front-end development, performance has always been a point that everyone pays attention to. However, the most intuitive way to judge the performance of a website is to look at the speed at which the web page opens. One of the ways to improve the response speed of web pages is to use caching. Caching technology has always played a very important role in the WEB technology system, and it is a means of quickly and effectively improving performance.

An excellent caching strategy can shorten the distance for web pages to request resources, reduce latency, and because cache files can be reused, it can also reduce bandwidth and network load.

When executing any query, SQL Server will read the data into the memory. After using the data, the data will not be deleted immediately, but will be cached in the memory Buffer. When the same data is obtained again, if all the required data If it is cached in memory, SQL Server will not generate Disk IO operations (importing data from the hard disk into memory), but will directly obtain data from memory. Because querying the data in the memory is very fast, the SQL Server engine will return the query results immediately. Caching data is a performance optimization mechanism of SQL Server.

1 WEB cache system

In the actual WEB development process, caching technology will involve different layers and different ends, such as: user layer, system layer, proxy layer, front-end, back-end, server, etc. The cache target of each layer is the same, that is Return the requested data as soon as possible to reduce delays, but each layer uses different technology implementations. Faced with the advantages and disadvantages of different layers and different ends, different technologies are selected to improve system response efficiency. Therefore, let's first look at what technologies and data are cached in each layer of caching. On the whole, we have an understanding of WEB caching technologies, as shown in the following figure:

2 Understanding browser cache

When a browser requests a website, it will load various resources, such as HTML documents, pictures, CSS and JS files. For some infrequently changing content, the browser will save them in a local file, and load these resources directly the next time you visit the same website to speed up access.

These files saved by the browser are called caches (not cookies or Localstorage).

After opening the website for the first time, if you refresh the page again. You will find that among the many resources loaded by the browser, some of them have specific sizes, but there are still some requests.

There are at least two obvious benefits of enabling caching in browsers:
(1) Reduce page loading time;
(2) Reduce server load;

Whether the browser uses the cache and how long it is cached is controlled by the server. To be precise, when a browser requests a web page (or other resource), certain fields in the "response header" part of the response sent back by the server indicate key information about the cache. Let's take a look at the header fields related to caching in the HTTP message:

1. General header fields (that is, fields that can be used in both request messages and response messages)
   
2. request header field
   
3. response header field

4. Entity header field

3 Browser caching mechanism

According to the different usage strategies of the above four types of header fields, caches in browsers can be divided into strong caches and negotiation caches :,

1. Strong cache:

Strong caching is mainly controlled by the Cache-Control and Expires fields in the response header. Among them, Expires is
defined in HTTP 1.0, which specifies an absolute expiration period. And Cache-Control is the cache control field that appeared in HTTP 1.1. Cache-Control:max-age defines a maximum usage period, which is the legal survival date from the first generation of the document to the cache no longer valid. Since Expires is a product of the HTTP1.0 era, there are some flaws at the beginning of the design. If the difference between the local time and the server time is too large, it will lead to cache confusion. When these two fields are used at the same time, the priority of Cache-Control is higher.
The effects of these two fields are similar, and the client will check whether the cache is available by comparing the local time with the server lifetime. If the cache does not exceed its lifetime, the client will directly use the local cache. If the time-to-live has passed, the cache is invalidated. The client will then communicate with the server again to verify that the cache needs to be updated.

2. Negotiation cache

If the strong cache mechanism detects that the cache is invalid, it needs to re-authenticate the server. This caching mechanism is also called negotiation caching. When the browser obtains the request for the first time, it will carry the last server modification date (Last-Modified) of the resource or the tag (Etag) of the resource in the response header. Subsequent request servers will judge whether the resources are invalid according to the If-Modified-Since (corresponding to Last-Modified) and (If-None-Match) fields on the request header. Once the resources expire, the server will resend new resources to the client On the end, so as to ensure the availability of resources.
The Last-Modified field corresponds to the last modification time of the resource, for example: , Last-Modified: Sat, 30 Dec 2017 20:18:56 GMTwhen the client requests the resource again, the If-Modified-Since field will be attached to the request header, and the value is the Last-Modified value returned before . If the resource has not expired and hits the cache, the server returns a 304 status code directly, and the client directly uses the local resource. Otherwise, the server resends the response resource.
Another method of verifying the negotiated cache is to pass the verification code instead of the time, so as to ensure that the network resources will not be repeatedly occupied when the file content remains unchanged. The Etag field in the response header is a mark that the server puts on the resource, and the cache can be updated by using this mark. Subsequent requests will have an If-None-Match field attached to the request header, and its value will be the value of this flag.
It should be noted that when both Etag and Last-Modified exist in the response header, the Etag will be compared first, and then Last-Modified.

3. Mechanism

1) When the browser loads a resource, it first judges whether it hits the strong cache according to some http headers of the resource. If the strong cache hits, the browser directly reads the resource from its own cache and does not send a request to the server. For example: a css file, if the browser loads the webpage where it is located, the cache configuration of the css file hits the strong cache, the browser will load the css directly from the cache, and even the request will not be sent to the server where the webpage is located ;
2) When the strong cache is not hit, the browser will definitely send a request to the server, and the server will verify whether the resource hits the negotiation cache according to other http headers of the resource. If the negotiation cache hits, the server will return the request , but will not return the data of this resource, but tell the client to load this resource directly from the cache, so the browser will load this resource from its own cache; 3) The common points of strong cache and negotiated
cache Yes: If it hits, the resource is loaded from the client cache instead of the resource data from the server; the difference is: the strong cache does not send the request to the server, and the negotiated cache sends the request to the server.
4) When the negotiation cache does not hit, the browser loads the resource data directly from the server.

4 Cache Judgment Process

If the resource has been cached by the browser, before the cache expires, when requesting again, it will check whether the strong cache is hit by default. If the strong cache hits, it will directly read the cache. If the strong cache is not hit, send a request to the server to check whether it hits. Negotiation cache, if the negotiation cache hits, it tells the browser that it can still read from the cache, otherwise it returns the latest resource from the server. The detailed flow chart of the browser judging the cache is as follows: ( network diagram )

(Partially taken from the Internet, the infringement will be deleted immediately)