Introduction

CDN is used to cache static resources on CDN nodes closer to the client in the scenario of static resource acceleration. Then, when the client accesses the resource, it can directly obtain the resource from the cache through a shorter link, avoiding the need to retrieve the static resource from the source through a longer link. Therefore, the hit rate of CDN cache directly affects the customer experience, and ensuring a high hit rate has become a core issue for webmasters. In this article, we will discuss the concept of CDN cache hit rate, its influencing factors, and optimization strategies together.

Part I: The Concept of Cache Hit Rate

Hit rate = (Total number of requests - Number of origin requests) / Total number of requests

The console can query the specific hit rate, as shown in the figure:

In the CDN request log, CDN records the caching hit status of all CDN requests, where the 'cache hit status' field is HIT indicating a hit, and MISS indicating a miss. One point to pay special attention to here is that the hit status here only indicates the hit status of CDN's L1 node. When the CDN's L1 node does not hit the cache but the L2 node hits the cache, it will still show MISS here.

Part II: Factors and Optimization Suggestions

1. Whether the file type is suitable for caching on CDN

CDN is responsible for accelerating static resources in the business architecture, so if dynamic resources also pass through CDN, it will lead to a decrease in the hit rate of CDN. CDN determines whether a file is dynamic or static by whether the response header of the file contains Etag and Last-modified headers. These two headers represent the modification status of the file through file content and file last modified time in the HTTP protocol.

Therefore, it is recommended that users optimize the following points during use:

Whether the website architecture is suitable for static and dynamic separation. Static and dynamic separation is a common website optimization strategy, mainly by separating static resources and dynamic resources into two sites to provide services. Since static resources do not change for a long time, they can be accelerated using CDN; while dynamic resources need to be fetched from the origin server in real-time and may take some time to load on the origin server (CDN has strict origin fetch timeout, and slow dynamic file response may cause CDN origin fetch to directly throw a 504 error).

Configure reasonable origin server caching rules. The origin server can configure caching rules for resources. When the following response headers are configured by the origin server, CDN will not cache the file:

1) If there is s-maxage=0, no-cache, no-store, or private among them

2) If there is no s-maxage or s-maxage=0, and there is max-age=0.

3) With Pragma: no-cache

And the above response headers will have the highest priority in CDN caching rules (even if caching rules are configured on CDN, they will not be cached), therefore, these response headers are not suitable for configuring on the static resources of the origin server. In addition, when there are no caching rules configured on CDN, the caching rules of the resources will follow the Cache-Control or Expires header of the origin server (the priority of Cache-Control is higher than that of Expires), so it is recommended that users set reasonable Cache-Control or Expires headers.

Configure cache rules. The scenario mentioned above, where the CDN cache time is 0 due to the absence of Etag and Last-modified headers, occurs when there is no cache configuration on the CDN console. Therefore, if the static resources of the user cannot be configured with the above two response headers, it is considered to configure cache rules for the file, so that the file can be cached according to the cache rules on CDN.

2. CDN Refresh and Preheat Features

The refresh feature refers to clearing all historical cache contents under a specific URL or directory. This operation is often used when the origin server performs a same-name update after which the CDN cache content has become historical dirty data. After refreshing, it will cause the URL to return to the source directly during the next visit, thus leading to a decrease in hit rate.

The preheating feature is to upload the URL in advance to the L2 node of CDN, so that resources do not need to be pulled from the origin server during the next visit. Therefore, preheating does not directly increase the hit rate of L1, but improves the real hit rate of CDN.

3. Rationality of CDN Cache Rules

CDN allows setting cache configurations for directories or file extensions. When both CDN and the origin server configure cache rules at the same time, the CDN's cache rules take precedence (unless the origin server sets rules that do not allow caching), so it is recommended that users set reasonable cache rules in the CDN console to avoid frequent returning to the source due to default cache rules (the default cache often caches for 3600 seconds before expiration).

4. Variable Parameters Lead to Decreased Hit Rate

The default processing logic in the CDN process is that requests with the same URL but different queryString are considered completely different requests. Therefore, the cache corresponds to different copies, which may lead to a re-source when the queryString parameters change, resulting in a decrease in hit rate.

The business system allows the use of the 'Filter Parameters' feature. After enabling the filter parameters feature, the CDN receives the URL with the queryString replaced by a URL without parameters.

5. Low Traffic of CDN Acceleration Domain

Some judgments indicate that the user traffic is low, and we have many service nodes. Since the first service needs to return to the source normally, this may lead to a high rate of returning to the source.