3 ms·

i don't see eye to eye with the author. afaik the only time a modern software developer needs to worry about backpressure is if they're using asynchronous or o

by a-dub 5y ago

i don't see eye to eye with the author. afaik the only time a modern software developer needs to worry about backpressure is if they're using asynchronous or otherwise non-flow-controlled i/o. neither of these cases nor even a discussion of synchronous vs. asynchronous i/o were mentioned.

bestcoder69 5y ago
I agree it’s less of an issue in more traditional, threaded req/reply servers. But queues can appear in a bunch of places. Like your load balancer may queue up connections from clients and dole them out to app servers as they free up capacity. Normally the queue is emptyish, but app servers will do backpressure via blocking as needed, so the load balancer connection queue fills. In this case you probably don’t even want to add capacity (to an extent) because what’s the point if clients have timeouts. Also eventually you might need a worker pool pulling from a queue. Just guessing, because they seem to appear eventually in/near web servers. You can spin up a bajillion lambdas simultaneously like a madman if you want, but odds are there’s a resource constraint on the source and/or destination data store side at least. So again you’ve got async execution, a growing queue, and bottlenecks to think about still. But maybe with threaded code it’s like a “pit of success” for traffic shaping. You only have so many threads you can use, so you configure a pool size and think about what happens when you’re at capacity, and define some nice predictable failure behavior and test it. (As opposed to the node.js server that will handle more connections but surprise you with a weird bottleneck that you don’t handle gracefully). So then the trad server developer can go longer (or forever) without being bitten by the queues that remain elsewhere in their system.
bborud 5y ago
They key is "flow controlled". Syncronicity doesn't really enter into it, but I can see how people can get confused and think it's about that because asynchronous designs tend to introduce a greater degree of decoupling.
colanderman 5y ago
Synchronous systems can benefit from backpressure. Clients can and do open multiple concurrent connections to such systems (common to work around the inevitable throughput limitations of synchronous systems)... it is still helpful to tell any given connections, no, I'm at my concurrency limit, any work you give me is just going to sit in a queue and increase your service time, so please don't.
- deleted 5y ago
  [deleted]

by a-dub 5y ago

bestcoder69 5y ago

I agree it’s less of an issue in more traditional, threaded req/reply servers. But queues can appear in a bunch of places. Like your load balancer may queue up connections from clients and dole them out to app servers as they free up capacity. Normally the queue is emptyish, but app servers will do backpressure via blocking as needed, so the load balancer connection queue fills. In this case you probably don’t even want to add capacity (to an extent) because what’s the point if clients have timeouts. Also eventually you might need a worker pool pulling from a queue. Just guessing, because they seem to appear eventually in/near web servers. You can spin up a bajillion lambdas simultaneously like a madman if you want, but odds are there’s a resource constraint on the source and/or destination data store side at least. So again you’ve got async execution, a growing queue, and bottlenecks to think about still. But maybe with threaded code it’s like a “pit of success” for traffic shaping. You only have so many threads you can use, so you configure a pool size and think about what happens when you’re at capacity, and define some nice predictable failure behavior and test it. (As opposed to the node.js server that will handle more connections but surprise you with a weird bottleneck that you don’t handle gracefully). So then the trad server developer can go longer (or forever) without being bitten by the queues that remain elsewhere in their system.

bborud 5y ago

They key is "flow controlled". Syncronicity doesn't really enter into it, but I can see how people can get confused and think it's about that because asynchronous designs tend to introduce a greater degree of decoupling.

colanderman 5y ago

Synchronous systems can benefit from backpressure. Clients can and do open multiple concurrent connections to such systems (common to work around the inevitable throughput limitations of synchronous systems)... it is still helpful to tell any given connections, no, I'm at my concurrency limit, any work you give me is just going to sit in a queue and increase your service time, so please don't.

deleted 5y ago
[deleted]