Live data from Hacker News

The 5-Hour CDN

fly.io

1–10 of 90 posts

Re: The 5-Hour CDN

#2
I like to blog from the raw origin and not use CDNs because if a blogpost is changed I have to manually purge the CDN cache, which can happen a lot. Also CDNs have the caveat in that if they're down, it can make a page load very slow since it tries to load the asset.

Re: The 5-Hour CDN

#3
post #2

I like to blog from the raw origin and not use CDNs because if a blogpost is changed I have to manually purge the CDN cache, which can happen a lot. Also CDNs have the caveat in that if they're down, it can make a page load very slow since it tries to load the asset.

If you’re okay with every request having the latency all the way to your origin, you can have the CDN revalidate its cache on every request. Your origin can just check date_updated (or similar) on the blog post to know if the cache is still valid without needing to do any work to look up and render the whole post.

To further reduce load and latency to your origin, you can use stale-while-revalidate to allow the CDN to serve stale cache entries for some specified amount of time before requiring a trip to your origin to revalidate.

Re: The 5-Hour CDN

#5
post #2

I like to blog from the raw origin and not use CDNs because if a blogpost is changed I have to manually purge the CDN cache, which can happen a lot. Also CDNs have the caveat in that if they're down, it can make a page load very slow since it tries to load the asset.

I set an s-maxage of at least a minute. Keeps my servers from being hugged to death while not having to invalidate manually.

Re: The 5-Hour CDN

#6
This is cool and informative and Kurt's writing is great:

The briny deeps are filled with undersea cables, crying out constantly to nearby ships: "drive through me"! Land isn't much better, as the old networkers shanty goes: "backhoe, backhoe, digging deep — make the backbone go to sleep".

Re: The 5-Hour CDN

#8
post #3
post #2

I like to blog from the raw origin and not use CDNs because if a blogpost is changed I have to manually purge the CDN cache, which can happen a lot. Also CDNs have the caveat in that if they're down, it can make a page load very slow since it tries to load the asset.

If you’re okay with every request having the latency all the way to your origin, you can have the CDN revalidate its cache on every request. Your origin can just check date_updated (or similar) on the blog post to know if the cache is still valid without needing to do any work to look up and render the whole post. To further reduce load and latency to your origin, you can use stale-while-revalidate to allow the CDN t…

> If you’re okay with every request having the latency all the way to your origin, you can have the CDN revalidate its cache on every request.

It's also worth mentioning that even when revalidating on every request (or not caching at all), routing through a CDN can still improve overall latency because the TLS can be terminated at a local origin server, significantly shortening the TLS handshake.

Re: The 5-Hour CDN

#10

fly.io has a fantastic engineering blog. Has anyone used them as a customer (enterprise or otherwise) and have any thoughts?

I've used them in the past. All I can say is that the support was (and probably still is) fantastic.
Post reply on HN