All Products
Search

This Product

    CDN:Improve cache hit ratio

    Document Center

    CDN:Improve cache hit ratio

    Last Updated:Apr 14, 2026

    A low cache hit ratio increases origin-fetch traffic, raises bandwidth consumption, and slows down resource delivery. Use the monitoring tools and optimization strategies to diagnose the cause and improve your ratio.

    How CDN caching works

    Alibaba Cloud CDN caches static content on globally distributed points of presence (POPs). When a request hits the cache, the POP serves the resource directly — no round-trip to the origin. A low cache hit ratio means more requests fall through to the origin, which increases latency, bandwidth costs, and server load.

    Byte hit ratio vs. request hit ratio

    CDN tracks two metrics:

    Metric

    Formula

    When to use

    Byte hit ratio

    (Traffic served by L1 POPs − Back-to-origin traffic served by L1 POPs) ÷ Traffic served by L1 POPs

    Default metric; reflects bandwidth efficiency

    Request hit ratio

    Requests that hit the CDN cache ÷ Total requests to CDN

    Secondary metric

    Focus on the byte hit ratio in most cases. A lower byte hit ratio means higher back-to-origin traffic, which increases bandwidth costs and origin server load. If range origin fetch is enabled, always use the byte hit ratio as your primary metric.

    Monitor your cache hit ratio

    In the console

    The CDN console displays the byte hit ratio. Two monitoring modes are available depending on the time window you need:

    Mode

    Time range

    Granularity

    Data latency

    Resource Monitoring

    Long periods, such as 30 days

    5 minutes

    ~15 minutes

    Real-time monitoring

    Short periods, such as 1 hour

    1 minute

    ~3 minutes

    For historical trend analysis, use Resource Monitoring.

    Cache hit ratio in Resource Monitoring

    For immediate diagnostics, use Real-time monitoring.

    Cache hit ratio in Real-time monitoring

    Via API

    Use these API operations to retrieve hit ratio data programmatically:

    Resource Monitoring (data up to 90 days)

    API

    Description

    DescribeDomainHitRateData

    Byte hit ratio for an accelerated domain name

    DescribeDomainReqHitRateData

    Request hit ratio for an accelerated domain name

    Real-time monitoring (data up to 7 days, 1-minute granularity)

    API

    Description

    DescribeDomainRealTimeByteHitRateData

    Real-time byte hit ratio for an accelerated domain name

    DescribeDomainRealTimeReqHitRateData

    Real-time request hit ratio for an accelerated domain name

    Improve the cache hit ratio

    Once you identify a low cache hit ratio, match the scenario below to your situation and apply the corresponding fix.

    Cause

    Scenario

    Solution

    No prefetch before traffic spikes

    Resources aren't cached on POPs before a product launch or major promotional event, so all initial requests go to the origin.

    Prefetch resources ahead of peak hours. See Refresh and prefetch resources.

    TTL too short or not configured

    POPs have no cache policy, or cached resources expire before they're requested again.

    Set a time-to-live (TTL) appropriate for the content type. See Configure a TTL.

    Query string parameters fragment the cache

    The same resource is requested using URLs that differ only in query string parameters, causing each variant to be treated as a distinct cache entry.

    Strip query string parameters from the cache key using the Ignore parameters feature. See Ignore parameters.

    Partial downloads inflate back-to-origin traffic

    A user downloads part of a large file (such as an installation package or video), but the POP fetches the entire file from the origin to fulfill the request.

    Enable range origin fetch so POPs retrieve only the requested byte range. See Configure range origin fetch.

    TTL guidelines by content type

    Set TTL values based on how often content changes:

    Content type

    Examples

    Recommended TTL

    Infrequently updated static content

    Images, installation packages

    1 month or longer

    Frequently updated static content

    JavaScript, CSS files

    1 day to 1 week, depending on update frequency

    Dynamic content

    PHP, JSP, ASP files

    0s (disable caching)

    Important

    If you use versioned file names (such as app.v2.js), you can safely set a longer TTL because each new version creates a new cache entry.

    Prefetch use cases

    Prefetch is especially effective in two scenarios:

    • Promotional activities: Before launching a large-scale campaign, push static resources for the activity page to POPs. When the activity goes live, all requests are served from cache with no origin round-trips.

    • Software releases: Before releasing a new version or update package, prefetch it to POPs so download requests are served directly from the edge, reducing origin load and improving download speeds.

    Advanced optimization policies

    Alibaba Cloud CDN provides the following advanced features for specific scenarios. To enable any of these features, contact Alibaba Cloud technical support:

    • Central 302 scheduling — redirects requests to the POP with cached content, avoiding redundant origin fetches across the CDN network.

    • Edge 302 scheduling — performs redirect-based scheduling at the edge to route users to a nearby POP that already holds the resource.

    • Merged origin fetch — when multiple POPs request the same uncached resource simultaneously, only one request is sent to the origin. The response is shared across all requesting POPs.

    • Shared cache — allows multiple accelerated domain names to share a single cache pool, which increases hit rates when domain names serve overlapping content.

    Read cache hit status from logs

    The CDN request logs record the cache hit status for every request. For the full log format, see Fields in offline logs.

    The HIT/MISS field in each log entry indicates whether the request was served from cache:

    Value

    Meaning

    HIT

    The request was served from the POP cache.

    MISS

    The request was not cached on the POP and was forwarded to the origin.

    The hit status reflects L1 POPs only. A request that misses on an L1 POP but hits on an L2 POP is still recorded as MISS.

    Log entry example:

    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"

    To download offline logs programmatically, call DescribeCdnDomainLogs to get the download URLs for your accelerated domain name.

    What's next