Improving the Cache Hit Ratio
Background
If the CDN cache hit ratio is low, the pressure on the origin server is high and the static resource access efficiency is low. You can select an optimization policy based on the cause of the low cache hit ratio to improve the cache hit ratio. In CDN, the cache hit ratio includes the traffic hit ratio and request hit ratio.
- Traffic hit ratio = Traffic generated by requests that hit the cache/Total traffic of requests
- Request hit ratio = Number of requests that hit the cache/Total number of requests
The traffic hit ratio indicates the load on the origin server. A lower traffic hit ratio means a larger retrieval traffic, which leads to a larger output traffic and higher bandwidth consumption on the origin server.
Viewing the Cache Hit Ratio
You can log in to the CDN console to view the traffic hit ratio and request hit ratio.
- Log in to the Huawei Cloud console. Choose .
The CDN console is displayed.
- In the navigation pane, choose .
- Choose Figure 1 Traffic hit ratio
Figure 2 Request hit ratio
and to view the traffic hit ratio and request hit ratio.
Optimizing the Cache Hit Ratio
- Set an appropriate maximum cache age.
CDN caches origin content on globally distributed PoPs so that users can obtain the content from nearby PoPs. You can set a proper maximum cache age for different content on the CDN console to improve the cache hit ratio.
- For static files (such as images and app packages) that are not frequently updated, set the maximum cache age to more than one month.
- For static files (such as JS and CSS files) that are frequently updated, set the maximum age based on service requirements.
- For dynamic files (such as PHP, JSP, and ASP files), set the maximum cache age to 0, so these files will not be cached on CDN PoPs.
For details, see Setting the Maximum Cache Age.
- If you have set Cache-Control to s-maxage=0, max-age=0, no-cache, no-store, or private on the origin server and enabled Origin Cache Control on the CDN console, CDN PoPs cannot cache origin content and will frequently retrieve content from the origin server. By default, Origin Cache Control is disabled.
- If your origin server has multiple hosts and the Last-modified, Etag, and Content-Length parameters of a resource on these hosts are set to different values, CDN PoPs cannot cache the resource and frequently retrieves the resource.
- If origin content has been updated, refresh the URLs of the content to ensure that users can obtain the latest content.
- If you have modified a cache rule, the new rule does not apply to content that has been cached but only applies to new content. If you want the modification to take effect immediately, refresh the cache after modifying the cache rule.
- Enable URL parameter filtering.
Currently, most web page requests carry URL parameters following a question mark (?). Parameters that do not contain important information (such as version) do not affect users' access to the correct content. You can configure URL parameter filtering to improve the cache hit ratio and distribution efficiency. For details, see "URL Parameter Filtering" in Cache Rules.
Typical applications
- When a user requests http://www.example.com/1.txt?test1 for the first time, the content is not cached on CDN, and CDN needs to retrieve that content from the origin server. If Ignore URL Parameters is enabled on CDN, when another user requests http://www.example.com/1.txt?test2, the parameter behind the question mark (?) will be ignored. As a result, the cache of http://www.example.com/1.txt is hit.
- When a user requests http://www.example.com/1.txt?test1 for the first time, the content is not cached on CDN, and CDN needs to retrieve that content from the origin server. If Ignore URL Parameters is disabled, when another user requests http://www.example.com/1.txt?test2, the full URL, including the parameter behind the question mark (?) will be matched. As a result, no cache is hit and CDN has to retrieve http://www.example.com/1.txt?test2 from the origin server.
- Preheat URLs.
CDN can proactively cache origin content to CDN PoPs through cache preheating. When users access the content, they can directly obtain the latest content from CDN PoPs. For details, see Cache Preheating.
When your domain name is connected to CDN for the first time, you can preheat origin content to CDN PoPs so that users can directly obtain the content from CDN PoPs, improving the cache hit ratio.
Typical scenarios
- Initial access to CDN: When a domain name is connected to CDN for the first time, the origin content is not cached on CDN PoPs. In this case, you can preheat the origin content to CDN PoPs. Then users can directly obtain the content from the nearest CDN PoP, improving the access speed.
- Installation package release: Before releasing a software installation package or upgrade package, you can preheat the content to CDN PoPs. After the software or upgrade is launched, the CDN PoPs directly respond to the download requests of a large number of users, which improves the download speed and greatly reduces the pressure on your origin server.
- Promotional activity: Before releasing a promotional campaign, you can preheat the static content involved on the activity page to CDN PoPs. After the activity starts, the CDN PoPs respond to user requests for accessing all static content, which ensures service availability and improves user experience.
- Enable range requests.
A range request allows the origin server to send a specific range of data to a CDN PoP using the range information in the HTTP request header. Range requests accelerate large file distribution and improve origin pull efficiency and cache hit ratio. For details, see Range Requests.
Typical scenarios
- If a user requests a clip of a video, CDN needs to retrieve the entire video from the origin server when Range-based retrieval is disabled. As a result, the retrieval traffic is greater than the traffic used for returning the content to the user, decreasing the cache hit ratio. When Range-based retrieval is enabled, CDN only needs to retrieve the clip of the video and returns the clip to the user, improving the cache hit ratio.
- Perform further operations.
- Do not update an entire directory when a specific cached content needs to be updated.
You can refresh the URL of the cached content to force the content cached on CDN PoPs to expire. Refreshing the entire directory will force all content in the directory to expire. When a user accesses a resource in the directory, no cache will be hit and CDN will need to retrieve content from the origin server. Therefore, do not refresh the entire directory, especially the root directory.
- Do not carry dynamic parameters in URLs.
If your URLs contain dynamic parameters, such as timestamps, CDN cannot cache the content and frequently retrieves the content.
- Do not update an entire directory when a specific cached content needs to be updated.
Checking Whether Requests for a URL Hit the Cache
- Open Google Chrome and press F12.
- Choose Network.
- Enter the website to be accessed in the address box and press Enter. View the response headers of the URL of a specific resource and perform the following operations:
- If the x-hcs-proxy-type header exists, check its value. The value 1 indicates that the cache is hit, and the value 0 indicates that the cache is not hit.
- If the x-hcs-proxy-type header does not exist, check the value of the X-Cache-Lookup header. Value Hit From MemCache, Hit From Disktank, or Hit From Upstream indicates that the cache is hit, whereas other values indicate that the cache is not hit.
- If neither the x-hcs-proxy-type nor X-Cache-Lookup header exists, check the value of the age header. Values greater than 0 indicate that the cache is hit, and the value 0 indicates that the cache is not hit.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot