Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The 5-Hour CDN

fly.io

Post reply on HN
Print view View original

11–20 of 90 posts

Re: The 5-Hour CDN

#11

Post by joshuakelly »

babelfish wrote: post #4

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

Yes, I'm using it. I deploy a TypeScript project that runs in a pretty straightforward node Dockerfile. The build just works - and it's smart too. If I don't have a Docker daemon locally, it creates a remote one and does some WireGuard magic. We don't have customers on this yet, but I'm actively sending demos and rely on it.

Hopefully I'll get to keep working on projects that can make use of it because it feels like a polished 2021 version of Heroku era dev experience to me. Also, full disclosure, Kurt tried to get me to use it in YC W20 - but I didn't listen really until over a year later.

Re: The 5-Hour CDN

#12

Post by simonw »

This article touches on "Request Coalescing" which is a super important concept - I've also seen this called "dog-pile prevention" in the past.

Varnish has this built in - good to see it's easy to configure with NGINX too.

One of my favourite caching proxy tricks is to run a cache with a very short timeout, but with dog-pile prevention baked in.

This can be amazing for protecting against sudden unexpected traffic spikes. Even a cache timeout of 5 seconds will provide robust protection against tens of thousands of hits per second, because request coalescing/dog-pile prevention will ensure that your CDN host only sends a request to the origin a maximum of once ever five seconds.

I've used this on high traffic sites and seen it robustly absorb any amount of unauthenticated (hence no variety on a per-cookie basis) traffic.

Re: The 5-Hour CDN

#13

Post by spondyl »

cj wrote: post #8
tshaddox wrote: post #3

Earlier quoted context omitted.

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.

Ah, the TLS shortening aspect of a CDN is something that seems obvious in hindsight but I'd never really thought about it. Thanks!

Re: The 5-Hour CDN

#14

Post by cgarvis »

babelfish wrote: post #4

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

just started to use them for an elixir/phoenix project. multi region with distributed nodes just works. feels almost magically after all the aws work I've done the past few years.

Re: The 5-Hour CDN

#15

Post by champtar »

cj wrote: post #8
tshaddox wrote: post #3

Earlier quoted context omitted.

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.

Also CDN providers will hopefully have good pearing. My company uses OpenVPN TCP on port 443 for maximum compatibility. When around the globe the VPN is pretty slow, so I proxy the tcp connection via a cheap VPS, and speed goes from maybe 500kbit/s to 10Mbit/s, just because the VPS provider pearing is way better than my company "business internet". (The VPS is in the same country as the VPN server).

Re: The 5-Hour CDN

#16

Post by tiffanyh »

cgarvis wrote: post #14
babelfish wrote: post #4

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

just started to use them for an elixir/phoenix project. multi region with distributed nodes just works. feels almost magically after all the aws work I've done the past few years.

What’s magically?

I was under the impression that fly.io today (though they are working on it) doesn’t do anything unique to make hosting elixir/Phoenix app easier.

See this comment by the fly.io team.

https://news.ycombinator.com/item?id=27704852

Re: The 5-Hour CDN

#17

Post by youngtaff »

Some of the things they miss in the post are Cloudflare uses a customised version or Nginx, same with Fastly for Varnish (don't know about Netlify and ATS)

Out of the box nginx doesn't support HTTP/2 prioritisation so building a CDN with nginx doesn’t mean you're going ti be delivering as good service as Cloudflare

Another major challenge with CDNs is peering and private backhaul, if you're not pushing major traffic then your customers aren't going to get the best peering with other carriers / ISPs…

Re: The 5-Hour CDN

#18

Post by vmception »

>The term "CDN" ("content delivery network") conjures Google-scale companies managing huge racks of hardware, wrangling hundreds of gigabits per second. But CDNs are just web applications. That's not how we tend to think of them, but that's all they are. You can build a functional CDN on an 8-year-old laptop while you're sitting at a coffee shop.

huh yeah never thought about it

I blame how CDNs are advertised for the visual disconnect

Re: The 5-Hour CDN

#19

Post by mike_d »

babelfish wrote: post #4

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

I run my own worldwide anycast network and still end up deploying stuff to Fly because it is so much easier.

The folks who actually run the network for them are super clueful and basically the best in the industry.

Re: The 5-Hour CDN

#20

Post by anonymoushn »

simonw wrote: post #12

This article touches on "Request Coalescing" which is a super important concept - I've also seen this called "dog-pile prevention" in the past. Varnish has this built in - good to see it's easy to configure with NGINX too. One of my favourite caching proxy tricks is to run a cache with a very short timeout, but with dog-pile prevention baked in. This can be amazing for protecting against sudden unexpected traffic spi…

Do you know if varnish's request coalescing allows it to send partial responses to every client? For example, if an origin server sends headers immediately then takes 10 minutes to send the response body at a constant rate, will every client have half of the response body after 5 minutes?

Thanks!

Post reply on HN