Cache LRU details

Follow
Brian

My site has very little traffic and pages take a long time to render so I can't count on traffic alone to warm the cache. I have been using a cron job to make period requests but am finding that my pages are being evicted form the cache much quicker than expected, sometimes just seconds or a couple minutes even with the following headers.

cache-control: public, s-maxage=86400, maxage=120, stale-while-revalidate=120

I suspect that the low volume of traffic is causing Fastly to evict my resources before the should be. Since traffic is so low it's hard to imagine that I'm using too much storage. 

Are there any headers or settings I can provide to improve retention in the cache? More information on the LRU rules mentioned here would be very helpful. There are no Set-Cookie headers and I have a fairly vanilla setup. The two main configurations are shielding and overriding the Host header on requests to the origin server (configured for the backend, not globally).

0

Comments

3 comments

Sort by Date Votes
  • Eden

    Hi Brian,

    Thank you for posting your question on our forums. Could you provide a test URL so that I can verify your findings? As you know, LRUs are based on the object size, the POP, object's request frequency and it's TTL. One thing I've seen often reduce how long we keep an object in cache is automated purges (PURGE ALLs and Surrogate Key purges) set by customers that might be affecting things unexpectedly. 

    0
    Comment actions Permalink
  • Brian

    You can try https://www.designmiami.com/browse/galleries-curio

    It's a NextJS app so kind of a hybrid server render and SPA. Initial page load and refreshes will fetch HTML while navigations through the site request a JSON bundle and do a client side page transition. 

    We do purge somewhat often since the site is under active development. Structure as well as content are changing frequently. 

    0
    Comment actions Permalink
  • Eden

    Thanks for that. From a cURL, I can see that you are setting s-maxage=86400. However, your max-age is shown as maxage. You'll want to update that to `max-age` instead. 

    curl -svo/dev/null -H "Fastly-Debug: true" https://www.designmiami.com/browse/galleries-curio
    * Trying 151.101.66.132:443...
    * Connected to www.designmiami.com (151.101.66.132) port 443 (#0)
    * ALPN, offering h2
    * ALPN, offering http/1.1
    } [5 bytes data]
    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
    } [512 bytes data]
    * TLSv1.3 (IN), TLS handshake, Server hello (2):
    { [122 bytes data]
    * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
    { [19 bytes data]
    * TLSv1.3 (IN), TLS handshake, Certificate (11):
    { [4036 bytes data]
    * TLSv1.3 (IN), TLS handshake, CERT verify (15):
    { [264 bytes data]
    * TLSv1.3 (IN), TLS handshake, Finished (20):
    { [52 bytes data]
    * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
    } [1 bytes data]
    * TLSv1.3 (OUT), TLS handshake, Finished (20):
    } [52 bytes data]
    * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
    * ALPN, server accepted to use h2
    * Server certificate:
    * subject: CN=www.designmiami.com
    * start date: Oct 26 03:37:26 2021 GMT
    * expire date: Jan 24 03:37:25 2022 GMT
    * subjectAltName: host "www.designmiami.com" matched cert's "www.designmiami.com"
    * issuer: C=US; O=Let's Encrypt; CN=R3
    * SSL certificate verify ok.
    * Using HTTP2, server supports multiplexing
    * Connection state changed (HTTP/2 confirmed)
    * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
    * Using Stream ID: 1 (easy handle 0x7fd12380d400)
    } [5 bytes data]
    > GET /browse/galleries-curio HTTP/2
    > Host: www.designmiami.com
    > user-agent: curl/7.78.0
    > accept: */*
    > fastly-debug: true
    >
    { [5 bytes data]
    * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
    { [193 bytes data]
    < HTTP/2 200
    < content-type: text/html; charset=utf-8
    < cache-control: public, s-maxage=86400, maxage=120, stale-while-revalidate=120
    < etag: W/"76bc6-G8b9gNMLIx9yyfLNuhnZ3Su9qZo"
    < surrogate-key: all_content template:browse shop:galleries-curio
    < cf-cache-status: DYNAMIC
    < expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
    < server: cloudflare
    < cf-ray: 6b0476023fd17120-SJC
    < accept-ranges: bytes
    < date: Thu, 18 Nov 2021 22:02:33 GMT
    < via: 1.1 varnish
    < age: 235
    < fastly-debug-path: (D cache-pdx12323-PDX 1637272954) (F cache-pdx12327-PDX 1637272718)
    < fastly-debug-ttl: (H cache-pdx12323-PDX 86165.062 0.000 235)
    < fastly-debug-digest: c0cb2b66165eb9835b57ed185dd585cd2a4763847d6b683bcbc07a21133c90de
    < x-served-by: cache-pdx12323-PDX
    < x-cache: HIT
    < x-cache-hits: 2
    < x-timer: S1637272954.639857,VS0,VE0
    < vary: Accept-Encoding
    < content-length: 486342
    <
    { [765 bytes data]
    * Connection #0 to host www.designmiami.com left intact


    The fastly-debug-ttl above shows us that we are caching things for the s-maxage specified 86400 seconds:

    < fastly-debug-ttl: (H cache-pdx12323-PDX 86165.062 0.000 235)

    https://developer.fastly.com/reference/http/http-headers/Fastly-Debug-TTL/

    I set a simple script to see how long your test URL would remain in cache. I still need to do some more testing but it does seem to be evicted quickly:

    for i in $(seq 0 60 12000); do sleep ${i}; echo -e "Sleep: ${i}\t $(curl -svo/dev/nul -H "Fastly-Debug: true" https://www.designmiami.com/browse/galleries-curio -H 'Fastly-Debug: true' 2>&1 | egrep 'Sleep:|(?i)X-Cache:|(?i)X-Served-By:|(?i)< age:|(?i)< date:' | tr '\r\n' '\t')"; done
    Sleep: 0 < date: Fri, 19 Nov 2021 01:06:52 GMT < age: 1355 < x-served-by: cache-pdx12329-PDX < x-cache: HIT
    Sleep: 60 < date: Fri, 19 Nov 2021 01:07:52 GMT < age: 1336 < x-served-by: cache-pdx12326-PDX < x-cache: HIT
    Sleep: 120 < date: Fri, 19 Nov 2021 01:09:52 GMT < age: 1536 < x-served-by: cache-pdx12328-PDX < x-cache: HIT
    Sleep: 180 < date: Fri, 19 Nov 2021 01:12:52 GMT < age: 1716 < x-served-by: cache-pdx12329-PDX < x-cache: HIT
    Sleep: 240 < date: Fri, 19 Nov 2021 01:16:52 GMT < age: 1956 < x-served-by: cache-pdx12334-PDX < x-cache: HIT
    Sleep: 300 < date: Fri, 19 Nov 2021 01:21:53 GMT < age: 2256 < x-served-by: cache-pdx12324-PDX < x-cache: HIT
    Sleep: 360 < date: Fri, 19 Nov 2021 01:27:53 GMT < age: 2616 < x-served-by: cache-pdx12334-PDX < x-cache: HIT
    Sleep: 420 < date: Fri, 19 Nov 2021 01:34:53 GMT < age: 3037 < x-served-by: cache-pdx12324-PDX < x-cache: HIT
    Sleep: 480 < date: Fri, 19 Nov 2021 01:42:53 GMT < age: 3517 < x-served-by: cache-pdx12334-PDX < x-cache: HIT
    Sleep: 540 < date: Fri, 19 Nov 2021 01:51:53 GMT < age: 4057 < x-served-by: cache-pdx12329-PDX < x-cache: HIT
    Sleep: 600 < date: Fri, 19 Nov 2021 02:01:54 GMT < age: 4577 < x-served-by: cache-pdx12326-PDX < x-cache: HIT
    Sleep: 660 < date: Fri, 19 Nov 2021 02:12:54 GMT < age: 5317 < x-served-by: cache-pdx12321-PDX < x-cache: HIT
    Sleep: 720 < date: Fri, 19 Nov 2021 02:24:58 GMT < age: 0 < x-served-by: cache-pdx12325-PDX < x-cache: MISS
    Sleep: 780 < date: Fri, 19 Nov 2021 02:38:02 GMT < age: 0 < x-served-by: cache-pdx12320-PDX < x-cache: MISS
    Sleep: 840 < date: Fri, 19 Nov 2021 02:52:03 GMT < age: 840 < x-served-by: cache-pdx12320-PDX < x-cache: HIT
    Sleep: 900 < date: Fri, 19 Nov 2021 03:07:07 GMT < age: 0 < x-served-by: cache-pdx12331-PDX < x-cache: MISS

    Do the purges you are doing affect the test URL provided? Can you let me know what kinds of purges your are making? Also, could you provide a URL that isn't getting purged regularly? 

    0
    Comment actions Permalink

Please sign in to leave a comment.

New post