> if (disableCommentsRanking.enabled == False) This could use some light-touch code reviewing
[deleted]
Defcon: Preventing overload with graceful feature degradation (2023)
51–60 of 107 posts
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#52Earlier quoted context omitted.
Facebook makes over 300 requests for me just loading the main logged in page while showing me exactly 1 timeline item. Hovering my mouse over that item makes another 100 requests or so. Scrolling down loads another item at the cost of over 100 requests again. It's impressive in a perverse way just how inefficient they can be while managing to make it still work, and somewhat disturbing that their ads bring in enough…
Wasn't the whole point of GraphQL in mitigating this?
Yeah, that's why you have only 100 requests* when you hover over an item instead of 800.
(* allegedly, didn't verify it myself)
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#53Am I reading the second figure right? Facebook can do 130*10^6 queries/second == 130,000,000 queries/second?!
Yes. And that was 4 years ago.
Must add that figure does NOT include static asset serving path.
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#54Earlier quoted context omitted.
Facebook makes over 300 requests for me just loading the main logged in page while showing me exactly 1 timeline item. Hovering my mouse over that item makes another 100 requests or so. Scrolling down loads another item at the cost of over 100 requests again. It's impressive in a perverse way just how inefficient they can be while managing to make it still work, and somewhat disturbing that their ads bring in enough…
Could someone tell me what these hundreds of requests could do?
Track you, probably with a thousand layers of redundancy, tech bloat, and decades of mold.
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#55Earlier quoted context omitted.
it's really great to have such capabilities, but adding them has a cost where only few can afford. Cost in terms of investing in building those, which impacts your feature build velocity and the maintenance
Can you be specific about the cost of building these? I've run into many situations where something was deemed costly, is found out later, and the team ultimately has implement it all while hoping no one groks that is was predicted. "Nobody ever gets credit for fixing problems that never happened" ( https://news.ycombinator.com/item?id=39472693 ) is related.
Effectively every piece of software written for at most a few thousand people to use concurrently (i.e. 99.99% of software).
Consumer apps that scale to hundreds of thousands of users with five 9s+ uptime requirements are very rare.
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#56Earlier quoted context omitted.
We’ve really wasted an incredible amount of talent-hours over last couple decades. Imagine if we’d worked on, like, climate change or something instead of ad platforms.
You make it sound like everybody at Meta works in the ads department.
Well, a lot of them do work directly on ads. Obviously not everybody, but a significant fraction. And most of the rest are just building things (products, features) to be able to show more ads.
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#57Earlier quoted context omitted.
it's really great to have such capabilities, but adding them has a cost where only few can afford. Cost in terms of investing in building those, which impacts your feature build velocity and the maintenance
Can you be specific about the cost of building these? I've run into many situations where something was deemed costly, is found out later, and the team ultimately has implement it all while hoping no one groks that is was predicted. "Nobody ever gets credit for fixing problems that never happened" ( https://news.ycombinator.com/item?id=39472693 ) is related.
For one, it potentially multiplies the testing and regression testing requirements to hit all those additional configurations.
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#58Earlier quoted context omitted.
We’ve really wasted an incredible amount of talent-hours over last couple decades. Imagine if we’d worked on, like, climate change or something instead of ad platforms.
The waste of talent hours is directly connected to climate change. The waste of network bandwidth is as well as the waste of compute cycles to run these "social" platforms. That all being said, as humans have free will, imagining what we "could have done" if we just _forced_ everyone to do something different is flirting with fascism.
Sure, I wouldn’t suggest forcing everyone to work on something else. We all could have been better, and the government could have tried to incentivize more productive work (they already provide incentives on way or another after all).
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#59Am I reading the second figure right? Facebook can do 130*10^6 queries/second == 130,000,000 queries/second?!
> Am I reading the second figure right? Facebook can do 130*10^6 queries/second == 130,000,000 queries/second?!
That sounds totally plausible to me.
Also keep in mind they didn't say what system this is. It's often true that 1 request to a frontend system becomes 1 each to 10 different backend services owned by different teams and then 20+ total to some database/storage layer many of them depend on. The qps at the bottom of the stack is in general a lot higher than the qps at the top, though with caching and static file requests and such this isn't a universal truth.
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#60> if (disableCommentsRanking.enabled == False) This could use some light-touch code reviewing
Some could argue it would be for illustration purpose, and not actual production code