Live data from Hacker News

The 5-Hour CDN

fly.io

71–80 of 90 posts

Re: The 5-Hour CDN

#71
post #41

Earlier quoted context omitted.

The thundering herd problem isn't really about high levels of traffic. To the extent that that's a problem, it's just an ordinary DOS. The thundering herd problem specifically refers to what happens if you coordinate things so that all your incoming requests occur simultaneously. Imagine that over the course of a week, you tell everyone who needs something from you "I'm busy right now; please come back next Tuesday a…

Hmm. I think of thundering Herd being about retries. All your failing requests batch up when your retry strategy sucks, then you end up really high traffic on every retry, and very little in between

Retries tend to amplify it, but a more common cause is scheduled tasks in clients/end user devices.

E.g. all clients checking for an update at 10:00 UTC every day, all clients polling for new data at fixed times, etc.

Re: The 5-Hour CDN

#73
post #60
post #37

Earlier quoted context omitted.

I still wouldn't say we do any magic Elixir stuff; rather, our platform just happens to have a combination of features (particularly edge delivery for stuff like LiveView and zero-config private networking for clustering) that make Elixir apps sing. But we've got full-time people working on Elixir now, too; we'll see where that goes. We've still got Elixir limerence here. :)

Hey Thomas, weren’t you running Latacora last time I checked?

I haven't been at Latacora for a while now.

Re: The 5-Hour CDN

#75
post #65

> 3. Be like a game server: Ping a bunch of servers and use the best. Downside: gotta own the client. Upside: doesn't matter, because you don't own the client. "If you can run code on it, you can own it". Your front page could just be a tiny loader js that fires off a fetch() for a zero byte resource to all your mirrors, and then proceeds to load the content from the first responder.

Now you just have the bad latency of the non-cached content, plus the ok latency of your CDN.

Re: The 5-Hour CDN

#76
> DNS: Run trick DNS servers that return specific server addresses based on IP geolocation. Downside: the Internet is moving away from geolocatable DNS source addresses. Upside: you can deploy it anywhere without help.

Can anyone expand on how/why "the Internet is moving away from geolocatable DNS source addresses"?

Re: The 5-Hour CDN

#77

Fly is great and I love reading their blog posts. Just hoping they come back around on CockroachDB-- I feel like it's a match made in heaven for what they're providing.

We love CockroachDB. There are people tinkering with it on Fly.io. I think anything formal would involve our companies talking to each other, which we're happy to do, but everybody is busy all the time. :)

Re: The 5-Hour CDN

#79
post #76

> DNS: Run trick DNS servers that return specific server addresses based on IP geolocation. Downside: the Internet is moving away from geolocatable DNS source addresses. Upside: you can deploy it anywhere without help. Can anyone expand on how/why "the Internet is moving away from geolocatable DNS source addresses"?

Some public/recursive DNS Servers like Cloudflare (1.1.1.1) do not tell the authoritative dns server the ip address or subnet of the requestor. Your ISP's DNS server usually does this. This makes CDN via DNS more difficult, as it is not always entirely clear from where the request comes (Cloudflare itself does not need this, they do everything with Anycast).

Re: The 5-Hour CDN

#80
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…

unrelated to CDNs but IIRC vitess did/does query coalescing too -- if it starts to serve a query for "select * from users where id = 123" and then another 20 connections all want the same query result, vitess doesn't send all 21 select queries to the backend, it sends the first one and then has all the connections wait on the backend response, then serves the same response to them all.

Vitess still does this. It can also do similar with writes on hot rows where someone is incrementing a counter for example.
Post reply on HN