Every day – x-litespeed-cache: hit but x-qc-cache: miss

  • Resolved rubiconcsl

    (@rubiconcsl)


    3 years, 10 months ago

    Hi all.

    I’m kind of new to this CDN stuff. I have installed the LS Cache plugin in WordPress. I have a feeling I must have something configured incorrectly.

    Every day, when I try the https://check.lscache.io testing link, I get “x-litespeed-cache: hit” but “x-qc-cache: miss”. Refresh and I get “x-qc-cache: hit”. I’m assuming there must be some sort of time limit I’ve set somewhere to tell quic.cloud to only cache the pages for a specific time. Should the cached page on quic.cloud stay there indefinitely, or at least until I force a refresh either manually, or using the crawler? I have a reasonably quiet site at the moment, so this currently means that pretty much every visitor is not getting the cached pages served – which kind of makes the CDN a bit of a waste of time right? I guess at least the Liteserver cache is persisting, but I’d like the quic.cloud cache to also persist.

    I’m only on a shared host at the moment, so I’m hoping to get some reasonabe performance without shelling out a lot of money for a more powerful server. They have been kind enough so far to enable the crawler for me, which I’ve left at default settings.

    Example test: https://check.lscache.io/?host=https%3A%2F%2Fnaomiraywoodreflexology.co.uk%2F. Again, tried just now and got “x-qc-cache: miss”. Refreshed and got “x-qc-cache: hit”.

    Any help for this amateur very much appreciated!

    Edit:-
    In case it helps, this is the output from testing another page on the site: https://check.lscache.io/?host=https%3A%2F%2Fnaomiraywoodreflexology.co.uk%2Fabout-me%2F

    HTTP/1.1 200 OK
    Connection: Keep-Alive
    Keep-Alive: timeout=5, max=100
    content-type: text/html; charset=UTF-8
    x-dns-prefetch-control: on
    x-litespeed-cache-control: public,max-age=492096
    x-litespeed-tag: 0e6_HTTP.200,0e6_page,0e6_URL.a3ac747154dd509932a1dab13d27e5f9,0e6_Po.162,0e6_PGS,0e6_guest,0e6_,0e6_MIN.922319a9e8a206729280f36c6942a2c4.css,0e6_MIN.3897d51d79b8ff90ac23af0c95a212dd.js
    etag: “286-1655011756;gz”
    x-litespeed-cache: hit
    vary: Accept-Encoding
    x-qc-cache: miss
    content-length: 62378
    content-encoding: gzip
    date: Mon, 13 Jun 2022 12:47:40 GMT
    server: LiteSpeed
    x-qc-pop: NA-US-LGA-33
    alt-svc: h3=”:443″; ma=2592000, h3-29=”:443″; ma=2592000, h3-Q050=”:443″; ma=2592000, h3-Q046=”:443″; ma=2592000, h3-Q043=”:443″; ma=2592000, quic=”:443″; ma=2592000; v=”43,46″

    • This topic was modified 3 years, 10 months ago by rubiconcsl.
    • This topic was modified 3 years, 10 months ago by rubiconcsl.
Viewing 3 replies - 1 through 3 (of 3 total)
  • serpentdriver

    (@serpentdriver)

    3 years, 10 months ago

    @rubiconcsl

    Plugin support will not be happy about my comment, but did you know that a CDN is not always faster as your own host? Do you have only visitors from your own country? Yes? Forget (any) CDN. If most of your visitors are from your own country a CDN doesn’t make your page faster, because too much “network hops” take part of the connection. A CDN like quic.cloud makes sense if you have a high rate of international visitors. LiteSpeed also communicates this in LiteSpeed blog, so you should weigh up, if you really need a CDN.

    Anyway, the difference between quic.cloud cache status and status of your own is “natural”. If you request your page quic.cloud displays the last known header for cache status and not the current status, because it is cached. If you request your page again quic.cloud checks your host headers again and updates them. This is why the cache status is not always equal. You can test the opposite if you request one of your pages that isn’t cached, then cache status is miss on both, CDN and your own host, but it becomes hit if you request the same page again.

    • This reply was modified 3 years, 10 months ago by serpentdriver.
    • This reply was modified 3 years, 10 months ago by serpentdriver.
    Thread Starter rubiconcsl

    (@rubiconcsl)

    3 years, 10 months ago

    @serpentdriver

    Thanks for the reply.

    I hadn’t picked up on the localisation bit. To be honest, all of the useful traffic will be very local (the site is for a reflexologist, so clients really do need to be close by). So, as you say, maybe the CDN is actually going to be slower. However, I am using a shared hosting solution currently, which does have limited resources. So I’m not sure how best to decide – I guess I’ll just have to try with and without quic.cloud.

    I’m afraid I haven’t quite understood your second paragraph regarding the details shown in the headers. Are you saying that the first load is actually not quite correct when it says the CDN is a miss?

    Thread Starter rubiconcsl

    (@rubiconcsl)

    3 years, 10 months ago

    I’ve just seen the following on https://quic.cloud/faq/#cache, which may have an impact in what I’m seeing: –

    Under the current CDN cache policy, pages are stored at a PoP for 24 hours from the last access. So, pages that don’t see much traffic will be removed from the PoP’s cache after about a day, but pages that are accessed at least once daily will remain in CDN cache up to 7 days.

    Future plans include tiered regional caching, which will increase the CDN cache hit rate and allow us to cache pages in a nearby node longer term.

    I’ll try making sure I access the homepage a few times a day and see if the MISS goes away.

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

The topic ‘Every day – x-litespeed-cache: hit but x-qc-cache: miss’ is closed to new replies.