How to improve the cache hit ratio of CDN - CDN - Alibaba Cloud Documentation Center

A low cache hit ratio increases origin server load, raises bandwidth costs, and slows content delivery. In this tutorial, you learn how to diagnose the cause of a low cache hit ratio and apply the appropriate optimization strategy using the Alibaba Cloud CDN console. By the end, you will have a systematic approach to maximizing cache performance for your accelerated domain.

Prerequisites

Before you begin, make sure that you have:

Added and enabled at least one accelerated domain name in the CDN console.
Permissions to manage CDN domain configurations, such as the AliyunCDNFullAccess policy.
Access to your origin server configuration, if you need to modify response headers.

Background information

Alibaba Cloud CDN caches content on edge nodes called points of presence (POPs). When a client requests a cached resource, the POP serves it directly without contacting the origin server. This reduces response time and origin load. A low cache hit ratio means more requests reach the origin, increasing latency and cost.

CDN provides two cache hit ratio metrics:

Byte hit ratio measures the proportion of data served from cache. A higher byte hit ratio means more data comes from the POP rather than the origin.
Byte hit ratio = (Traffic served by L1 POPs - Back-to-origin traffic) / Traffic served by L1 POPs
Note
A lower byte hit ratio means more back-to-origin traffic, which increases bandwidth costs and origin load. Therefore, the byte hit ratio is the primary metric to monitor for cache performance.
Request hit ratio measures the proportion of requests served from cache, regardless of file size.
Request hit ratio = Cache-hit requests / Total requests to CDN
Note
In most scenarios, especially when range-based origin fetch is enabled for large files, use the byte hit ratio as your primary metric. The request hit ratio is useful for understanding how many requests are served from cache regardless of file size.

View the cache hit ratio

Method 1: Use the console (recommended)

Use the console for quick, one-time checks of your cache hit ratio. The CDN console displays the byte hit ratio through two monitoring features:

Resource monitoring — View cache hit ratio trends over longer periods, such as 30 days. Data is available at 5-minute granularity with a delay of approximately 15 minutes. For more information, see Resource monitoring.
Real-time monitoring — View real-time cache hit ratio over shorter periods, such as 1 hour. Data is available at 1-minute granularity with a delay of approximately 3 minutes. For more information, see Real-time monitoring.

Method 2: Call API operations

Use API operations if you need to integrate cache hit monitoring into dashboards, scripts, or automated alerting systems.

API operation	Description
DescribeDomainHitRateData	Retrieves byte hit ratio data for an accelerated domain. Standard granularity (5-minute or hourly). Query data from the past 90 days.
DescribeDomainReqHitRateData	Retrieves request hit ratio data for an accelerated domain. Standard granularity (5-minute or hourly). Query data from the past 90 days.
DescribeDomainRealTimeByteHitRateData	Retrieves real-time byte hit ratio data at 1-minute granularity for an accelerated domain. Query data from the past 7 days.
DescribeDomainRealTimeReqHitRateData	Retrieves real-time request hit ratio data at 1-minute granularity for an accelerated domain. Query data from the past 7 days.
DescribeCdnDomainLogs	Retrieves log download URLs for an accelerated domain. Query logs from the past 90 days.

Increase the cache hit ratio

Start by checking your CDN logs to identify the most common cause of cache misses for your domain. Then apply the corresponding strategy from the table below.

Strategy	Factors and scenarios	Configuration method
Prefetch popular resources	Factors: Before large-scale events or new version releases, resources not yet cached on POPs trigger origin fetches, lowering the cache hit ratio. Scenarios: For promotional events, preheat static resources of the event page to POPs before the event starts. For application releases, preheat installation packages before launch so that download requests are served from POPs.	Use the prefetch feature to preheat resources to POPs. For more information, see Quick start.
Configure an appropriate cache expiration period	Factors: No cache policy configured on CDN, or the configured TTL is too short. All user requests reach the origin, or cached resources expire frequently. Scenarios: You published static content on the origin, but POPs do not cache it, or cached content expires quickly. Guidance: For static files that are rarely updated (images, application downloads), set the TTL to one month or longer. For frequently updated static files (JS, CSS), set the TTL based on your business needs. For dynamic files (PHP, JSP, ASP), set the TTL to 0 seconds to disable caching. Note: Setting a long TTL may serve outdated content. Use file versioning (such as appending a version number to the filename) or purge the cache after updating content.	Configure CDN cache expiration
Ignore URL parameters in the cache key	Factors: URLs with different query parameters that point to the same resource trigger separate cache entries and origin fetches. Scenarios: You want different URLs with different parameters (such as tracking IDs or timestamps) to access the same cached resource.	Ignore parameters
Configure range-based origin fetch for large files	Factors: When users download only a portion of a large file (such as an installer or video), the POP fetches the entire file from the origin without range-based origin fetch. The POP downloads more data from the origin than it serves to users, lowering the byte hit ratio. Scenarios: Users downloading application installation packages or streaming video content.	Configure range origin fetch
Handle origin no-cache headers	Factors: The origin server returns no-cache response headers (such as `Cache-Control: max-age=0`, `Cache-Control: no-cache`, or `Cache-Control: private`), preventing CDN from caching the resource. All requests are forwarded to the origin. Scenarios: The origin server sends `Cache-Control: max-age=0` or `Cache-Control: no-cache` for static files (images, JS, CSS), preventing POPs from caching these resources.	Method 1 (recommended): Modify the origin server configuration to remove no-cache headers from static resource responses and set a reasonable cache duration (for example, `Cache-Control: max-age=2592000`). This addresses the root cause at the origin level, ensuring CDN receives correct caching directives. Method 2: In the CDN console, navigate to Domain Names > click the target domain name > Cache tab > Cache Expiration Period. Add a cache rule and enable Ignore Origin No-Cache Header. When enabled, CDN ignores the origin server's no-cache headers and caches resources according to the cache expiration rules configured in the CDN console. Use Method 2 only when you cannot modify the origin server configuration. Warning: Ignoring origin no-cache headers may cause CDN to cache content that the origin server intentionally marked as non-cacheable, potentially serving outdated files. Only enable this feature if you are certain the origin server's no-cache headers are misconfigured.
Other optimization strategies	In addition to the strategies above, Alibaba Cloud CDN provides additional optimization features for specific scenarios: Central 302 redirection: Schedules user requests to the optimal origin node through a 302 redirect from a central dispatch server. Edge 302 redirection: Schedules user requests to the nearest optimal origin through a 302 redirect from the edge POP. Shared cache: Allows multiple accelerated domain names under the same Alibaba Cloud account to share cache resources on POPs. When multiple domain names (such as A.example.com and B.example.com) require the same JS or CSS files and the origin content is identical, shared cache lets these domain names share a single cached copy, improving the cache hit ratio. When adding a new website, you only need to align its resource paths with the existing accelerated domain name's resource structure.	Central 302 redirection, edge 302 redirection, and origin fetch aggregation are configured by Alibaba Cloud after-sales engineers. Contact support to enable these features. Shared cache: In the CDN console, navigate to Domain Names > click the target domain name > Cache > Shared Cache. Click Modify, select a target domain name from the list of online accelerated domain names under your account (search is supported), and confirm. After configuration, the current domain name shares the cache with the selected domain name and merges into its origin fetch path. To remove the configuration, click Delete Configuration and confirm. Note: Ensure that domain names sharing cache serve identical content. Shared cache may expose one domain's content to another domain's users if paths overlap.

Note

To revert any cache configuration change described in the table above, return to the same settings page in the CDN console and delete or disable the rule.

View cache hit status in logs

CDN request logs record the cache hit status for each request.

The cache hit status field in logs indicates one of the following:

HIT — The request was served from the POP cache.
MISS — The request was not served from the POP cache and was fetched from the origin.

Note

The hit status reflects the L1 POP only. If a request misses the cache on the L1 POP but hits the cache on the L2 POP, the log still shows MISS.

Example log entry:

[26/Jun/2019:10:38:19 +0800] 192.168.53.146 - 1542 "-" "GET http://example.aliyundoc.com/index.html" 200 191 2830 MISS "Mozilla/5.0 (compatible; AhrefsBot/5.0; +http://example.com/robot/)" "text/html"

In this example, the MISS status indicates the resource was not cached on the L1 POP. If your logs show a high proportion of MISS entries, refer to the strategies in the Increase the cache hit ratio section to identify and address the cause.

You can also call the DescribeCdnDomainLogs API operation to retrieve log download URLs for an accelerated domain.

Verify the optimization

After applying an optimization strategy, verify that the cache hit ratio has improved:

Wait for cache propagation. Cache configuration changes typically take effect within 5 minutes. If you extended the cache TTL, you may need to purge old cached content for changes to apply immediately.
Check the cache hit ratio. Use the Real-time monitoring feature in the CDN console or call DescribeDomainRealTimeByteHitRateData to check the current byte hit ratio. Compare the results with your baseline before the optimization.
Review the logs. Check recent log entries for an increased proportion of HIT status entries. A well-optimized CDN typically achieves a byte hit ratio of 80% or higher for static-heavy workloads.