Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defcon: Preventing overload with graceful feature degradation (2023)

micahlerner.com

Post reply on HN
Print view View original

61–70 of 107 posts

Re: Defcon: Preventing overload with graceful feature degradation (2023)

#61

Post by scottlamb »

mikerg87 wrote: post #38

Isn't this referred to as Load Shedding in some circles? If its not, can someone explain how its different?

They're the same thing or close to it. "Load shedding" might be a bit more general. A couple possible nuances:

* Perhaps "graceful feature degradation" as a choice of words is a way of noting there's immediate user impact (but less than ungracefully running out of capacity). "Load shedding" could also mean something less impactful, for example some cron job that updates some internal dashboard skipping a run.

* "feature degradation" might focus on how this works at the granularity of features, where load shedding might mean something like dropping request hedges / retries, or individual servers saying they're overloaded and the request should go elsewhere.

Re: Defcon: Preventing overload with graceful feature degradation (2023)

#62

Post by goatking »

baby wrote: post #25
bee_rider wrote: post #18

Earlier 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.

found the meta employee

Re: Defcon: Preventing overload with graceful feature degradation (2023)

#64

Post by nostrademons »

zerkten wrote: post #36
tuyguntn wrote: post #34

Earlier 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.

When I was in Search 15 or so years ago, there was actually a very direct cost: revenue.

The AdMixer was an "optional" response for the search page. If the ads didn't return before the search results did, the search would just not show ads, and Google wouldn't get any revenue for it. Showed the premium that Google of the day put on latency and user experience. I think we lost a few million per year to timeouts, but it was worth it for generating user loyalty, and it put a very big incentive on the ads team to keep the serving stack fast.

No idea if it's still architected like that, I kinda doubt it given recent search experiences, but I thought it was brilliant just for the sake of aligning incentives between different parts of the organization.

Re: Defcon: Preventing overload with graceful feature degradation (2023)

#65

Post by spencerflem »

akira2501 wrote: post #49
bee_rider wrote: post #18

Earlier 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.

I think most devs also would rather work on something good too, but those jobs are rare and pay worse. That's the part that needs fixing

Re: Defcon: Preventing overload with graceful feature degradation (2023)

#67

Post by OrsonSmelles »

ipaddr wrote: post #41
ipaddr wrote: post #40

Earlier quoted context omitted.

It's directly in the link you provided. "For example, an active user can be measured as a user that has logged back into her account to interact with the product in the last 30 days." Even the marketing material is designed to confuse.

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' for examples where gender is irrelevant or unknown is strictly better, but it's hard for me to summon a lot of contempt for someone who goes with a different/older habit.

Re: Defcon: Preventing overload with graceful feature degradation (2023)

#68

Post by ndriscoll »

yodsanklai wrote: post #46
ndriscoll wrote: post #15

Earlier 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?

A lot of them appear to be that they've split their javascript into a gazillion files for whatever reason (I suppose because they have several MB of it). But someone or lots of people there did seem to get addicted to dynamic loading. Like I've got 100 or so friends, but my friends page loads them 8-16 at a time as I scroll. Just send all 100 and set the profile pictures to deferred fetch. It'd probably be smaller than the js they have to make it do "infinite" scroll.

Similarly, after getting to the bottom of their "infinite" scroll, my friend feed (which is annoyingly hidden away) gives me... 15 items. Just send me all 15. It's like 1-2 kB worth of data. If you're going to end the scroll after a dozen items, why is it using infinite scroll?

Re: Defcon: Preventing overload with graceful feature degradation (2023)

#70

Post by zer00eyz »

golergka wrote: post #24
ndriscoll wrote: post #15

Earlier 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?

No.

Here is the thing, hypermedia is cacheable. React/Graphql not so much.

Facebook is now just an application that runs in the browser.

As a poor, small developer who doesn't want to hemorrhage money, I tend to want things to be more hypermedia and less app. It saves on complexity and bandwidth and costs.

Post reply on HN