• Resolved Nazar78

    (@nazar78)


    Hello,

    Can I know how long is the cache on the CDN? Does it honor the origin cache headers? Take example the header below, first request I got a miss which is normal, 2nd request minutes apart I got a hit which is also normal. But the next day I got a miss again requesting from the same location in Asia. I noticed in my server logs the CDN is doing origin pull again for all static contents the next day. This daily origin pull seems to slow down the process instead of speeding up the site. I’ve also tried removing the etag, same occurrence. Could you help to advise? Thank you!

    HTTP/1.1 200 OK
    Date: Mon, 27 Apr 2020 12:35:47 GMT
    Content-Type: image/png
    Content-Length: 12558
    Connection: keep-alive
    Last-Modified: Tue, 16 Feb 2016 20:25:36 GMT
    ETag: "56c385c0-310e"
    Content-Encoding: gzip
    Expires: Tue, 27 Apr 2021 12:35:47 GMT
    Cache-Control: max-age=31536000
    Server: Shift8_CDN
    Access-Control-Allow-Origin: http://xxxxxxxxx
    X-Shift8CDN-Cache: MISS
    Pragma: public
    Cache-Control: public
Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author shift8

    (@shift8)

    Hello!

    We are setting an expires tag as well as cache-control headers for a 1 year expiration. Where a pull will happen is if the query string changes for the requeted file (i.e. style.css?ver=1.0 versus style.css?ver=1.1).

    Thats interesting about the 1 day re-pull. Just to clarify you were hitting the same endpoint each time you tested? Its possible you hit another endpoint , but if you were testing from the asia endpoint each time then I can attempt to look into this further.

    There may be other factors that caused the cache to refresh but I would want to run some tests to see – is this for every static asset (images, css, js) , or is this for just some? If you could send an email to [email protected] withe the site url , I can look further also.

    Thread Starter Nazar78

    (@nazar78)

    Hi there,

    Thanks for getting back so quickly, didn’t noticed you replied as I got no notification despite opting for it.

    Just to clarify you were hitting the same endpoint each time you tested?

    Anyway, yes I tested from the same origin endpoint in asia SG everytime. It’s being pulled by the CDN in OVH SG. I checked from both Chrome dev with cache disabled and curl head.

    is this for every static asset (images, css, js) , or is this for just some?

    From what I noticed, it’s happening for every static assets. Below is one of such:

    https://iplw1glkkmpj.wpcdn.shift8cdn.com/wp-content/uploads/2016/01/WDMyCloud4TB-qBittorrent-150×58.png

    There may be other factors that caused the cache to refresh

    I’m aware about the query string changes but would love to know more about the other factors. Also would it cache both with and without query string? Thank you.

    Plugin Author shift8

    (@shift8)

    Hello,

    Thank you for your added information and assistance with understanding your issue.

    There are certain behaviours and practices that will be happening behind the scenes to optimize the process of the CDN. Some of these are best practices , for example :

    If an asset is cached in the CDN, there is a time window it will stay held in the cache. If nobody accesses it at all within the window of time, it will naturally expire. This is intended to optimize the network so that we aren’t holding assets that nobody is accessing.

    What this really means is the busier your site is, the longer (or permanently) the assets will stay held in the cache. If during after hours, someone doesn’t access an asset for more than an hour (the way the CDN is configured now), it will naturally expire and go stale.

    I have facilitated the increase of this behaviour time window to be a bit more generous. Please understand, especially for a free CDN, we have to take these types of precautions to ensure that we dont overload the network. Also understand that this behaviour for a caching system is actually by design and a best practice (so its not just us).

    That said , I would consider improving this even further for paid users. Again the default time window has increased from 60 minutes (if nobody accesses an asset at all, it expires), to 180 minutes, for free plan users.

    Does this make sense? I think this may be what you were seeing. I dont think the expires was happening in a day but was likely just the content going stale. I would be willing to investigate further if you have other suggestions, of course.

    Thread Starter Nazar78

    (@nazar78)

    Hello thanks again for replying.

    Ok I understood but doesn’t this impact the CDN network bandwidth by doing double job again and again in a short period? That is pulling again from origin then serve to the endpoint repeatedly every few hours. Retaining them longer on the edge may save the bandwidth at the slight cost of storage. IIRC one of the other free CDN provider kept it for few days hence I was puzzled why I was getting many misses in a short period with Shift8 but you already given the explanation.

    Anyway thank you for providing this great service.

    Plugin Author shift8

    (@shift8)

    I’ll continue looking into this – I appreciate your understanding. You are correct in your assessment, it would be much more efficient to keep the asset longer.

    Plugin Author shift8

    (@shift8)

    I’m closing this issue as its more of a feature change at this point. I will continue to investigate this and roll it out any necessary improvements in a future update.

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘Cache length’ is closed to new replies.