8 ms·

In an era of unlimited scaling infrastructure, it's a shame they're struggling to capitalize on an exclusive superbowl scale marketing event. It was predictable

by nell 4y ago

In an era of unlimited scaling infrastructure, it's a shame they're struggling to capitalize on an exclusive superbowl scale marketing event. It was predictable days in advance.

alldayeveryday 4y ago
Days is not enough advance notice, if for example they don't have a way to monetize the traffic. Unlimited scale = unlimited cost. Potentially the site crashing was the financially appropriate outcome.
- nnx 4y ago
  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.
  - woweoe 4y ago
    The website is a sort-of voluntary enthusiast thing where subscription fees cover the costs of everything.
    - tpmx 4y ago
      Their 2021 revenue was $25M.
  - tshaddox 4y ago
    I would be surprised if that's not already the architecture of a website like this, especially if keeping infrastructure costs low is a significant requirement for the business.
  - Aachen 4y ago
    Somebody pays for that bandwidth though?
- cosmolev 4y ago
  They surely do know how to monetize the traffic. Banners are all over the website.
  - BbzzbB 4y ago
    Will people coming in from Twitter and co specifically to check in on Pelosi's plane have any interest in converting to a subscriber for general flight tracking? I'd suspect the conversion rates would be (/are) extremely low with this kind of inorganic traffic.
- kragen 4y ago
  It's not unlimited scale, it was just over 700_000 people according to https://news.ycombinator.com/item?id=32320697 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 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 http://canonical.org/~kragen/sw/dev3/server.s (docs in http://canonical.org/~kragen/sw/dev3/httpdito-readme 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 https://news.ycombinator.com/item?id=32319147 says, "Use one big server." The associated article https://specbranch.com/posts/one-big-server/ 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 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.
seydor 4y ago
Do they really want lots of traffic? It's a very specialized website, it's not like the traffic will stick. The people who want to pay for their services are already customers. I doubt they care about random Joe
- polio 4y ago
  This is exactly it. It's likely a better business decision to just crash in this scenario.
nell 4y ago
Their infrastructure might very well be setup in a way that can't scale. They don't need unlimited scaling for the entire site, just enough to scale for one particular plane. They make money from ads and subscriptions. Any such business pays for user acquisition and a % of users convert to subscriptions. Even if all this is spiky traffic, their site probably has now had millions of first-time users. When traffic dies down, they will settle back at a higher than previous usual levels.
tjpnz 4y ago
Having used it for many years I cannot recall a time when it's been fast.
sdfgdfghj 4y ago
A single employee live-streaming on Twitch would do the trick. :) Flithradar24 can pay me later for the tip.
falcolas 4y ago
Bank accounts ultimately put a hard cap on scaling infrastructure. Considering most folks use this service for free, I can't imagine they'd want to let those free users DDOS their bank account into bankruptcy. Cloud infrastructure is expensive.
petethepig 4y ago
I’d argue they got more coverage because they went down.

by nell 4y ago

In an era of unlimited scaling infrastructure, it's a shame they're struggling to capitalize on an exclusive superbowl scale marketing event. It was predictable days in advance.

alldayeveryday 4y ago

Days is not enough advance notice, if for example they don't have a way to monetize the traffic. Unlimited scale = unlimited cost. Potentially the site crashing was the financially appropriate outcome.

nnx 4y ago
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.
- woweoe 4y ago
  The website is a sort-of voluntary enthusiast thing where subscription fees cover the costs of everything.
  - tpmx 4y ago
    Their 2021 revenue was $25M.
- tshaddox 4y ago
  I would be surprised if that's not already the architecture of a website like this, especially if keeping infrastructure costs low is a significant requirement for the business.
- Aachen 4y ago
  Somebody pays for that bandwidth though?
cosmolev 4y ago
They surely do know how to monetize the traffic. Banners are all over the website.
- BbzzbB 4y ago
  Will people coming in from Twitter and co specifically to check in on Pelosi's plane have any interest in converting to a subscriber for general flight tracking? I'd suspect the conversion rates would be (/are) extremely low with this kind of inorganic traffic.
kragen 4y ago
It's not unlimited scale, it was just over 700_000 people according to https://news.ycombinator.com/item?id=32320697 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 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 http://canonical.org/~kragen/sw/dev3/server.s (docs in http://canonical.org/~kragen/sw/dev3/httpdito-readme 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 https://news.ycombinator.com/item?id=32319147 says, "Use one big server." The associated article https://specbranch.com/posts/one-big-server/ 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 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.

seydor 4y ago

Do they really want lots of traffic? It's a very specialized website, it's not like the traffic will stick. The people who want to pay for their services are already customers. I doubt they care about random Joe

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

nell 4y ago

Their infrastructure might very well be setup in a way that can't scale. They don't need unlimited scaling for the entire site, just enough to scale for one particular plane. They make money from ads and subscriptions. Any such business pays for user acquisition and a % of users convert to subscriptions. Even if all this is spiky traffic, their site probably has now had millions of first-time users. When traffic dies down, they will settle back at a higher than previous usual levels.

tjpnz 4y ago

Having used it for many years I cannot recall a time when it's been fast.

sdfgdfghj 4y ago

A single employee live-streaming on Twitch would do the trick. :) Flithradar24 can pay me later for the tip.

falcolas 4y ago

Bank accounts ultimately put a hard cap on scaling infrastructure. Considering most folks use this service for free, I can't imagine they'd want to let those free users DDOS their bank account into bankruptcy. Cloud infrastructure is expensive.

petethepig 4y ago

I’d argue they got more coverage because they went down.