Live data from Hacker News

The Thundering Herd Problem

encore.dev

21–30 of 38 posts

Re: The Thundering Herd Problem

#21

Hey - just wanted to give props to the author. I always enjoy Encore content when it pops up here. Brand is cool too

Although I just checked your pricing on a whim and it's the most expensive per member service I've ever seen for devs. By a LOT. I mean I still like the brand but wow.

Encore CEO here. Thanks for the feedback.

We sell developer productivity and devops automation, and compared to hiring additional engineers Encore is very cheap.

We’ve tried to align our incentives with the needs of our customers, so there are no usage-based or surprise fees when using Encore. The per-seat price may be higher but it’s transparent and predictable.

Re: The Thundering Herd Problem

#22

Once again, what TFA describes is NOT the thundering herd problem. https://en.wikipedia.org/wiki/Thundering_herd_problem > In computer science, the thundering herd problem occurs when a large number of processes or threads waiting for an event are awoken when that event occurs, but only one process is able to handle the event . (emphasis mine)

Thundering herd has evolved beyond the original definition, that happens. Sometimes terms even flip their meaning (like how "one bad apple" has flipped it's meaning, or how "pre-optimization is the root of all evil" as used these days isn't what the original author actually meant, but in this case I think most of the new usages fit the basic idea, which is a large amount of unusual traffic happens outside of normal u…

Fair point that terms like this can change meanings.

But this version absolutely does not fit the original, which had nothing to do with amounts of traffic.

It was a problem with kernel APIs: if N threads sleep waiting for an event on a socket (i.e. a thread pool), there was no way to wake up only one of them when a single msg arrived. They would all wake, all check if there was work to do, then all (but one) would go back to sleep. This is a behavioral flaw even in the case of next to no traffic (though it may not have an material effect).

The problem has been solved with better kernel APIs.

Re: The Thundering Herd Problem

#23

As someone who has worked on very large networks for 15 years, the author left out some important bits about using caching with thundering herd problems. You really need to make sure that your cache settings will not generate a ton of requests to the origin when new content is requested. If you have a bunch of clients that are going to request content at nearly the exact same time (this happens a lot with live video…

I recall seeing that called "Request coalescing" in Faster Than Lime's article https://fasterthanli.me/articles/request-coalescing-in-async...

Re: The Thundering Herd Problem

#25
Philosophically, the "thundering herd problem" actually CAUSES congestion.

There are 2 ways to handle it.

1 Stop the thundering herd.(make all the clients do something different). That may make things worse. Congestion in networks is usually exponential. You can't fulfill a request so you repeat the request, it can't be fulfilled so it repeats. You can add a random delay at the client end but that is just The US governments answer to the debt problem, it kicks the can down the road in the short term but it will almost certainly come back and bite you. Mathematically it is very easy for this scenario to become catastrophically exponential when a threshold is reach

2 Stop the congestion (make the handling process faster or add processes)

The system already has a cache to handle this but if its not in the cache it doesn't help. There needs to be an extra request cache exclusively for congestion scenarios. The existing cache request is already doing some processing, so extend that to route "thundering herd requests processing". This second cache does a bit more processing as well.As each new request is routed to it, it checks itself to see if this requestor is in the cache and removes it or overwrites it. It should never contain more than one entry per client.

When no more editions are made to this congestion cache (or the rate has slowed significantly) then the requests can be forwarded and processed via the original cache system.

Under this configuration, the congestion does not become exponential and should only delay the thundering herd requests. All other requests will be handled as per normal.

Once the original cache has the information there is no need for any thundering herd requests to be routed to the congestion cache.

Some clients will encounter some delays but not all and only on the "thundering herd process".

Re: The Thundering Herd Problem

#26
post #14

Earlier quoted context omitted.

For those who don't have the weird systemd allergy, systemd has many great features, including random scheduling, see `RandomizedDelaySec`.

Oh yes, systemd in general and timers in particular do have a whole bunch of awesome stuff - I just tend to forget any of it exists, it's my coping mechanism for dealing with "heterogeneous" environments. I still have CentOS6 machines in prod... https://www.freedesktop.org/software/systemd/man/latest/syst...

Yeah a lot of those nice things like random delays, back offs, evening using timezones are not available, even in the centos7 systemd.

Re: The Thundering Herd Problem

#27

As someone who has worked on very large networks for 15 years, the author left out some important bits about using caching with thundering herd problems. You really need to make sure that your cache settings will not generate a ton of requests to the origin when new content is requested. If you have a bunch of clients that are going to request content at nearly the exact same time (this happens a lot with live video…

I recall seeing that called "Request coalescing" in Faster Than Lime's article https://fasterthanli.me/articles/request-coalescing-in-async...

It is also sometimes called request collapsing.

Re: The Thundering Herd Problem

#28

As someone who has worked on very large networks for 15 years, the author left out some important bits about using caching with thundering herd problems. You really need to make sure that your cache settings will not generate a ton of requests to the origin when new content is requested. If you have a bunch of clients that are going to request content at nearly the exact same time (this happens a lot with live video…

Yep, Ive found that, generally, caching logic should be a separate flow from business logic. E.g wrap your RPC logic such that an in-memory cache transparently sits in your RPC stack. This lets you implement locking on the cache in a single place, and makes it easy to do things like eager prefetching or offloading cache logic to another thread.

Re: The Thundering Herd Problem

#29
post #19
post #7

Earlier quoted context omitted.

Do you mean something like "at most once" delivery over UDP?

No, that's more like traditional load shedding. I'm talking more like Kafka/NATS/0mq/etc.

Sure, but that's just moving most of the chaos from your app to a message bus. Which is almost always correct, assuming you are actually at the scale where you need that level of architectural complexity.

Re: The Thundering Herd Problem

#30
post #29
post #19

Earlier quoted context omitted.

No, that's more like traditional load shedding. I'm talking more like Kafka/NATS/0mq/etc.

Sure, but that's just moving most of the chaos from your app to a message bus. Which is almost always correct, assuming you are actually at the scale where you need that level of architectural complexity.

I wouldn't agree that it is moving reliability issues to the message bus. This is more a scaling/availability problem than a reliability problem, but the message bus is definitely helping to solve scaling/availability problems.

While Kafka can indeed be pretty complex, streaming architectures aren't necessarily complex at all. For example, having a AWS Kinesis stream sitting in front of an AWS Lambda is pretty simple, and provides efficiency benefits even at comparatively small scale.

Post reply on HN