Am I reading the second figure right? Facebook can do 130*10^6 queries/second == 130,000,000 queries/second?!
Whats with people lately writing 10^6 instead of 1 million. Its not that big that we need exponents to get involved.
Defcon: Preventing overload with graceful feature degradation (2023)
71–80 of 107 posts
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#72Am I reading the second figure right? Facebook can do 130*10^6 queries/second == 130,000,000 queries/second?!
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…
Do you have an ad blocker stopping the requests and causing retries?
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#73Earlier quoted context omitted.
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.
The developer, tester and devops time required to properly implement graceful degradation could easily accumulate to hundreds of hours. Those hours are directly expensive when your developers cost hundreds of dollars a day; and have a material opportunity cost in that their commitment to one particular project delays the delivery of other features. Moreover, any new features would have to be made compatible with the…
When you hire an engineer to build a dam, you expect them to consider piping and subsurface flows such that the foundation isn't swept out in a decade. No matter of the engineer was already paid, retired, etc.
My point isn't that we all need to make dams that can hold up for a century. The point is that you hire an engineer because you want someone with the judgement and expertise to apply the correct amount of engineering to any given solution. Over-engineering is on the pathway to correct-sized engineering. It's the experience, discovery, and exploration required to arrive at choosing what things actually do not need to be done.
When your manager asks you, "do we really need to do that?" It's the expert that can explain why it really is necessary, and the professional who accepts "we're not going to do that" as an answer. And if they still feel it would be harmful not to do it, then that's where professional duty kicks in.
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#74Earlier quoted context omitted.
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.
The developer, tester and devops time required to properly implement graceful degradation could easily accumulate to hundreds of hours. Those hours are directly expensive when your developers cost hundreds of dollars a day; and have a material opportunity cost in that their commitment to one particular project delays the delivery of other features. Moreover, any new features would have to be made compatible with the…
[deleted]
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#75Earlier 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…
Do you have an ad blocker stopping the requests and causing retries?
I do have ublock origin on everything of mine, so conceivably it's reacting to that somehow. I'm no longer at my computer to be able to look more closely at what it's doing.
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#76Earlier quoted context omitted.
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.
The developer, tester and devops time required to properly implement graceful degradation could easily accumulate to hundreds of hours. Those hours are directly expensive when your developers cost hundreds of dollars a day; and have a material opportunity cost in that their commitment to one particular project delays the delivery of other features. Moreover, any new features would have to be made compatible with the…
There's a lot of levels to the approach.
Just spending a few moments to consider whether queues should grow, block, or spill when adding them makes a big difference, along with choices in error handling. You can get a lot of things to gracefully degrade for free if that's a part of your decision-making process.
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#77Earlier quoted context omitted.
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.
The developer, tester and devops time required to properly implement graceful degradation could easily accumulate to hundreds of hours. Those hours are directly expensive when your developers cost hundreds of dollars a day; and have a material opportunity cost in that their commitment to one particular project delays the delivery of other features. Moreover, any new features would have to be made compatible with the…
Could be as simple as just some feature flags with environment variables
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#78Earlier quoted context omitted.
It should be their account not her account (or his). Who writes this garbage.
Alternating or stochastically varying pronouns in your examples used to be a common way to make an effort at inclusive writing, usually preferred aesthetically to constructs like `his/her'. (The style before that was basically to use masculine pronouns for hypothetical people in every single case and deny that there was anything to question about that.) I think I agree that the modern semi-standard of using `they' fo…
[deleted]
Re: Defcon: Preventing overload with graceful feature degradation (2023)
#79Earlier 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…
This is the company that instead of ditching PHP created a full on PHP to C++ transpiler and then deployed their while site on that for a few years.
> deployed their while site
??