On: S3 was down

[kccqzy]

Programmatically purging caches is slow and costs extra. Just use normal cache-busting techniques like a different URL after a deployment.

EDIT: Oops. Misread cloudflare/CloudFront.

[manigandham → kccqzy]

Cloudflare and all other modern CDNs do this instantly and for free. Only the legacy ones take longer (usually minutes at most) and might charge a small extra.

[jsjohnst → manigandham]

Akamai takes far longer than a few minutes if you use all their POPs. It's in the 6-12hr range.

[jsizzle → jsjohnst]

This is not true. Purges on akamai take less than ten minutes for entire cp codes or specific objects. Deploying new cache rules is less than an hour in many cases

[jsjohnst → jsizzle]

How many POPs are you using? I can assure you, I am not wrong here and have internal knowledge of why if you are truly using all POPs it takes so long.

[notyourday → jsjohnst]

That's not correct. Site delivery on Akamai globally is purged within several minutes

[jsjohnst → notyourday]

Look, I know what I'm talking about. Just because you can purge faster because of a different deployment doesn't mean that's the case for everyone. "Fast Purge" is not available for every type of deployment.

[nothrabannosir → jsjohnst]

> Look, I know what I'm talking about.

Thanks for replying, but unless you're willing to explain to the rest of us why so, why bother? I can't make heads or tails of this pissing contest thread.

[notyourday → jsjohnst]

You are confused.

"Site Delivery" is purged globally within 7 minutes.

"Fast purge" enabled products (site delivery) is purged globally in under 20 seconds.

All assets for websites are site delivery. Only media services family of products are not site delivery. Those purge within a couple of hours. If you are someone who uses media services products, you know how to force Akamai to go back to origin globally instantaneously and how to trigger invalidation. In media services you should never serve stale.

[jsjohnst → notyourday]

As I said, it depends on your deployment. Thanks for the reply and confirming what I said was correct, that under some deployments it can be a multi-hour purge.

[sumobob → jsjohnst]

the new fast purge utility is much faster too

[sgl75 → kccqzy]

Changing URLs is not really an option for html pages of a static site.

[_hyn3 → sgl75]

Only for the root of a site, but there are better cache expiration options as noted elsewhere anyway.

For inner pages, browsers do consider /your-page-url?v=1505418887 to be a completely different page from /your-page-url?v=1505418888.

However, just expiring cache and/or properly setting HTTP cache control headers at most CDN's is a cleaner and more correct option.

[sgl75 → _hyn3]

I'm not following. How does that help my visitor see the latest version of the page when coming from a search engine or external site?

[_hyn3 → sgl75]

Exactly, it doesn't. That's why you should use the actual cache mgmt options from your CDN provider, or just wait for your (properly configured) cache control headers to expire the cache (bear in mind that intermediate caching proxies don't always obey those TTLs or dates either).

I was just pointing out that some people adjust their menu links (etc) to include some sort of dynamic variable (ie /?ts=xxx). I don't recommend this sort of scheme, though, except in unusual circumstances: IMO, it's fragile, leaky, and inefficient.

[tokenizerrr → kccqzy]

No it's not? It's free to just purge everything.

[hamandcheese → kccqzy]

Thats fine for assets, but not at all ideal for pages.