How to flush the Fastly cache

How-to Guides
,
#1

Goal

To purge all cached assets from the CDN layer sitting in front of your site.

Assumptions

You will need:

  • To have Fastly cache running in front of your site
  • The ability to run curl from your local terminal,
  • Working access to the platform command for your project
    OR
  • Read access to the Variables on your project through the web console.

Problems

For most Enterprise or Premium plans, The Platform.sh setup team has configured Fastly CDN for you, and manages it on your behalf with a built-in account. This means you do not have direct administration access using the Fastly web UI, where a ā€˜Purgeā€™ button can be found.

However, you have been issued with an ā€œAPIā€ key that allows you access to many actions on your account, and you can initiate a purge using this.

To purge a single page

Fastly lets you purge individual URLs with no authentication.

curl -X PURGE $url

Thatā€™s it!

To Purge all

You need use the API key.

All projects with Fastly configured should have had the env:FASTLY_API_TOKEN set in their
/master/settings/variables

Some older dedicated plans do not have it here, and the API token is instead stored in a text file on the server. If you canā€™t find the value in the environment variables, check for a file called /mnt/shared/fastly_tokens.txt on your server.

This key can be used to construct a purge_all API request.

The Fastly API documentation says to construct a request like this:

POST /service/SU1Z0isxPaozGVKXdv0eY/purge_all HTTP/1.1
Fastly-Key: YOUR_FASTLY_TOKEN
Accept: application/json

So, from a local CLI, run this sequence to retrieve your keys:
(or you can just set the variables to the values you can see in the web console yourself)

FASTLY_SERVICE_ID=$(platform --project=$PROJECTID --environment=master variable:get env:FASTLY_SERVICE_ID --pipe)
FASTLY_API_TOKEN=$(platform --project=$PROJECTID --environment=master variable:get env:FASTLY_API_TOKEN --pipe)
# Legacy: If these environment variables do not exist on your installation, try looking for a file called `/mnt/shared/fastly_tokens.txt` instead.

FASTLY_API_URL="https://api.fastly.com"
    
curl -H "Fastly-Key: $FASTLY_API_TOKEN" \
  -X POST "${FASTLY_API_URL}/service/${FASTLY_SERVICE_ID}/purge_all"

eg:

curl -H "Fastly-Key: nfDDFUahPwV4wQiJOMbLwJsCBy3Wh4TQ" -X POST "https://api.fastly.com/service/nOBmPqIK5M71NgZMhLYTZk/purge_all"

{"status":"ok"}

^ mind the quotes there.

Verify it really worked

To empirically test, you could retrieve a page from your site and see if it looks right :slight_smile: , or immediately make a network request and check the cache headers and dates:

curl -I -s $url

HTTP/2 200
...
cache-control: max-age=3600, public
last-modified: Fri, 06 Mar 2020 01:36:16 GMT
date: Fri, 06 Mar 2020 02:26:54 GMT
...
via: 1.1 varnish
age: 0
x-served-by: cache-syd10142-SYD, cache-hkg17927-HKG
x-cache: MISS, MISS

The x-served-by and via confirm that a cache is working.
Unless someone else has already requested this page just ahead of you, you should see a MISS in the x-cache.
Either way, the age (in seconds) should be low, and the date should be fresh. Ignore the last-modified

Verify via API (just FYI)

To verify the command ran as expected, you can retrieve a list of the recent events, with a command like:

curl -H "Fastly-Key: $FASTLY_API_TOKEN"  -X GET "${FASTLY_API_URL}/events?page[number]=1&page[size]=10"

ā€¦which should return a response including something like:

    {
      "id": "miaXP6k1OLwUdOIXcKkiHG",
      "type": "event",
      "attributes": {
        "customer_id": "rSam6DCAgeyDU7gSoC5pJi",
        "description": "Purge all was performed",
        "event_type": "service.purge_all",
        "ip": "118.173.60.218, 118.173.60.218",
        "metadata": {},
        "service_id": "ZknOBmPqIK5M71NgZMhLYT",
        "user_id": "TdqCvp120Tm185r3gn4DYR",
        "created_at": "2020-03-06T01:35:35Z",
        "admin": false
      }
    },

Conclusion

This is a quick method to flush your CDN cache as needed.

There are many other actions possible through the Fastly API though not all will be available to the account granted with that API key.

If you are using a CMS like Drupal, then a Fastly module can be installed to integrate cache management into your CMS. This provides an easier interface to actions like this. This approach also lets the CMS invoke a CDN purge when things change, so is recommended if you need to tune things finer.

2 Likes
How to Check my Fastly CDN peformance (Cache hit ratio)
#2

Can use the API to check the fastly service performance also.
One important thing is the hit ratio. To see what itā€™s been like in the last 24 hours:

Iā€™m on OSX, where the date function is non-standard, so Iā€™ll use php to generate a timestamp for yesterday to define a request range.

For Grid, where the environment is master, do this. If your production environment is named differently, adjust accordingly.

FASTLY_SERVICE_ID=$(platform --project=$PROJECTID --environment=master variable:get env:FASTLY_SERVICE_ID --pipe)
FASTLY_API_TOKEN=$(platform --project=$PROJECTID --environment=master ssh "echo \$FASTLY_API_TOKEN")
FASTLY_API_URL="https://api.fastly.com"
yesterdayTS=$(php -r "echo(strtotime('yesterday'));")

curl -s -H "Fastly-Key: $FASTLY_API_TOKEN" \
    "${FASTLY_API_URL}/stats/service/${FASTLY_SERVICE_ID}?by=day&from=${yesterdayTS}" \
    | jq ".data[].hit_ratio"

example response:

0.7552160529016075

75% is not great.

There are a hundred other sats in that response you can investigate also.

Try

curl -s -H "Fastly-Key: $FASTLY_API_TOKEN" \
    "${FASTLY_API_URL}/stats/service/${FASTLY_SERVICE_ID}?by=day&from=${yesterdayTS}" \
    | jq -r '.data[] | "hits:\(.hits)" , "miss:\(.miss)" , "pass:\(.pass)" , "----",  "requests:\(.requests)"  '

for a slightly extended report.

hits:6624
miss:2147
pass:25633
----
requests:34446

This shows that the fastly report of 75% ā€œCache hit ratioā€ may be misleading as a guide to app performance, as the vast majority of the requests here were given a PASS, and Fastly chooses to not count PASS in the hit/miss summary.
In this case, the number of requests hitting the server vs the number of requests that Fastly intercepted is MUCH greater than it seems.

So your app may be suffering badly even when Fastly says itā€™s being efficient!