4 ms·

You may be forgetting that load balancers have been working on a per request basis, and that no two requests are the same cost (despite what load balancer compa

You may be forgetting that load balancers have been working on a per request basis, and that no two requests are the same cost (despite what load balancer companies would have you believe). Under HTTP/1.1 requests may have been hitting the LB and then being scattered across a dozen machines. Each of those machines was in a position to respond on their own time scale. Some requests would get back quickly, others slowly, but still actively being handled. Under HTTP/2 with multiplexing, if the LB isn't set up to handle it (and they often aren't) they can be hitting the LB and _all_ ending up on a single machine, which is trying to process them while some of those requests might be requiring more significant processor resources, dragging the response rate for all the requests down simultaneously.

deleted 8y ago
[deleted]
Aaargh20318 8y ago
> if the LB isn't set up to handle it (and they often aren't) they can be hitting the LB and _all_ ending up on a single machine According to the author “we do load balance by request, not connections and we do not use sticky sessions.” (Source: https://news.ycombinator.com/item?id=19722637 https://news.ycombinator.com/item?id=19722637)
ec109685 8y ago
ALB allows for 128 simultaneous requests over one connection and de-multiplexes them by creating individual http/1.1 requests to servers in a round robin fashion: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html https://docs.aws.amazon.com/elasticloadbalancing/latest/appl...