FlightRadar24 crashes due to surge in users tracking SPAR19

Where does Betteridge's Law come into play?

Seems like a significant security risk that it is publicly trackable?

I've seen AF1 land at the airport here (Bozeman) -- it flew in to the area at high altitude then circled tightly reducing altitude until final approach. I assumed to reduce the chance of a stinger hit from mountain-men.

Nancy Pelosi is the Speaker of the US House of Representatives. She is 2 heartbeats away from being President (she would become president if both the President and Vice President became incapacitated).

The House is similar to the UK Parliament. She is elected to her position by the members of the House.

Since Democracts control the House this term, they elected Nancy Pelosi as Speaker for this term.

The President has primary responsibility for foreign affairs. The Speaker taking this action could be interpretted as stepping on the toes of the President, or could have tacit approval of the President as a kind of stalking horse.

Yeah, seems they don't have much coverage in Indonesia and the Philippines. I wonder if FR24 (which was showing the flight path correctly all along) depends on private uploaders there, or do they have other data sources to fill the gaps.

Yep, it doesn’t filter military flights (which has been interesting recently - toggle by clicking the “U” UI button)

I like to bring this up whenever FlightRadar24 is mentioned.

They heavily censor their feed. Not only for military aircraft, but they also have a service where you can pay to have your aircraft hidden by the system.

Personally my beef with them is that they started as a paid app, then transitioned to a subscription model and left everyone who bought the app hanging.

FR24 also uses a network of volunteer feeders. The difference is that FR24 uses that volunteer data and monetizes it. ADSB Exchange shares it back to the community.

This is exactly it. It's likely a better business decision to just crash in this scenario.

Days in advance would have been enough to prepare a static page for SPAR19 alone, updated minutely or something... would cost practically nothing, especially if served from CDN edges.

They surely do know how to monetize the traffic. Banners are all over the website.

It's not unlimited scale, it was just over 700_000 people according to https://news.ycombinator.com/item?id=32320697. If your web page is 100 kilobytes, which seems like the maximum that would be reasonable, that's 70 gigabytes of traffic. AWS charges US$0.09 per GB so this is US$7. If you eliminate the cloud premium it's closer to US$1.

In fact loading their home page takes 3.1 MB for me over two minutes. Searching for a flight (AAL301 in this case since SPAR19 has already landed) brings this to 3.8 MB. At this size it would be 266 gigabytes, US$27. Reloading the page, I see that this was about 180 HTTP hits, though a lot of those were ads (I guess they have a way to monetize the traffic) which were blocked by uBlock Origin.

But doesn't it take a lot of CPU and RAM to serve 700_000 page views, especially at 180 hits per page view? That's 126 million hits, after all! Well, of course you can write your code arbitrarily inefficiently. According to https://crozdesk.com/software/fastly/pricing Fastly charges US$0.0075 per ten thousand hits, so if you could serve all those hits from Fastly it would cost you just under US$100. And probably if you're getting 700_000 people looking at the same thing you should figure out how to make all those hits cacheable either in Fastly or in something slower but cheaper. This probably isn't the first popular flight on FlightRadar24, even if it's the first one that's this popular.

(Also though you probably don't need 180 hits to serve up a single page. One for HTML, one for JS, one for CSS, one for an icon sprite sheet, and maybe half a dozen map tiles. The cause of death was a self-inflicted wound.)

What if we want to know the minimal CPU cost to serve up 126 million hits rather than the minimal dollar cost for someone else to serve them up for you? Well, one weekend a few years ago I wrote a static file HTTP web server called httpdito-386: http://canonical.org/~kragen/sw/dev3/server.s (docs in http://canonical.org/~kragen/sw/dev3/httpdito-readme). It's 710 lines of code and can handle 20_000-30_000 hits per second on my ten-year-old laptop (8 cores) and push about 1.8 gigabits per second of traffic. It's not the most efficient web server (it forks a new process for every connection and drops the connection after handling the first request) but it's probably adequate to get a ballpark figure.

Serving up 126 million hits with httpdito would take 84 minutes on my ten-year-old laptop, so probably you'd have needed 2-5 server machines, or one machine that wasn't ten years old. Serving up 70 gigabytes in a smaller number of hits would have taken 5 minutes.

Of course, the whole point of FlightRadar24 is that it's giving you dynamically updated Comet information about where flights are, not just serving up precomputed files from the filesystem. You could implement this kind of functionality by polling, but using Comet would probably be more efficient. Maintaining 700_000 open connections is easily within the capacity of a single server today; we were doing several thousand on our Comet server at KnowNow in 02000, using what we called RUTH (Robert's Ugly Thttpd Hack), using select() on a 32-bit machine with a gigabyte of RAM and a gigahertz.

https://news.ycombinator.com/item?id=32319147 says, "Use one big server." The associated article https://specbranch.com/posts/one-big-server/ profiles the servers they use at Azure: two 64-core CPUs with a 2-2.5 GHz clock, 4-6 instructions per clock, 256 MiB (MB?) of L3 cache, and 1 TiB (TB?) of RAM. From the cloud pricing they're citing, buying one probably costs about US$15k, roughly the cost of one programmer-week. According to https://news.ycombinator.com/item?id=32321406, FlightRadar24's revenue in 02021 was US$25M, so this would be a little less than 6 hours of their revenue.

There's no excuse.

Back when S3 and EC2 were brand spanking new services, and EC2 didn't have persistent disks, I got to see a quite well designed analytics pipeline. The inbound tracking http requests went into a pool that aggregated them locally in mysql, then wrote out the database files to S3. A separate pool would pull down these files and merge them into a local mysql databases for the web app UI. So kindof like a very simplistic map reduce atop s3 using mysql ISAM files.

It was impressively simple to keep running, and they easily scaled it to handle massive spikes related to sports events and such. The only real downside is the delay in new data hitting the UI layer, but this was built out while a lot of people still had webtrends installs kicking around, so it was perfectly acceptable for their customers.

Actually no, not calling it republic of China would make the other China angry. Taiwan would like to call itself Taiwan.

Am amused at the baby blue and pink colored suits the two people are wearing.