4 ms·

I thought I remembered reading somewhere that techniques like this only move the back-pressure to other parts of the system rather than solve the problem. There

I thought I remembered reading somewhere that techniques like this only move the back-pressure to other parts of the system rather than solve the problem. There's a load point beyond which you have almost no choice but to throw requests away. It was something like [1] but I don't think that was the exact article I read. [1] http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html http://mechanical-sympathy.blogspot.com/2012/05/apply-back-p...

dragonwriter 12y ago
> I thought I remembered reading somewhere that techniques like this only move the back-pressure to other parts of the system rather than solve the problem. I think that redirecting to an alternate asynchronous mechanism via a "send us an email" notification is essentially equivalent to an automated shift to an asynchronous mechanism in terms of shifting load to a different part of the system -- doing either is appropriate only if you've got a process for handling asynchronous requests that won't fall-over (or produce results unacceptably out of user expectations) under load despite the fact that processing requests synchronously would. Lots of times, however, this is the case, so long as you don't have a long-term load problem, but only a spiking load problem. > There's a load point beyond which you have almost no choice but to throw requests away. Yes, but that point differs depending on how you are processing requests -- and (for a system with direct human interactions) how you are setting client UX expectations.
bkirwi 12y ago
Probably this one? http://ferd.ca/queues-don-t-fix-overload.html http://ferd.ca/queues-don-t-fix-overload.html Queues and similar things help flatten out the spikes, but they don't add capacity. Like many of these tools, use with discretion.
- breckinloggins 12y ago
  Yes, that one. Thank you.

dragonwriter 12y ago

> I thought I remembered reading somewhere that techniques like this only move the back-pressure to other parts of the system rather than solve the problem. I think that redirecting to an alternate asynchronous mechanism via a "send us an email" notification is essentially equivalent to an automated shift to an asynchronous mechanism in terms of shifting load to a different part of the system -- doing either is appropriate only if you've got a process for handling asynchronous requests that won't fall-over (or produce results unacceptably out of user expectations) under load despite the fact that processing requests synchronously would. Lots of times, however, this is the case, so long as you don't have a long-term load problem, but only a spiking load problem. > There's a load point beyond which you have almost no choice but to throw requests away. Yes, but that point differs depending on how you are processing requests -- and (for a system with direct human interactions) how you are setting client UX expectations.

bkirwi 12y ago

Probably this one? http://ferd.ca/queues-don-t-fix-overload.html http://ferd.ca/queues-don-t-fix-overload.html Queues and similar things help flatten out the spikes, but they don't add capacity. Like many of these tools, use with discretion.

breckinloggins 12y ago
Yes, that one. Thank you.