Concurrency/rate limiting/queuing for HTTP apps, is, I agree, certainly not a trivial thing. You want to be maximizing utilization of your available host resources, while minimizing latency even under unexpected loads (for both median and upper percentiles). Dealing mostly with CPU resource limits, but other issues can be IO contention or contention for limited shared resources like an rdbms, while also not maxing out your RAM.
As with anything involving concurrency and hard-to-predict-exactly usage patterns, it can easily get complicated.
This stuff ain't easy. Anyone who thinks this would only happen to an unusually "wrong" app, I think, hasn't looked into it seriously. This post was good information, I think it's unfortunate that so much of the discussion seems to be trying to shame the author (making it less likely people in the future will generously share such post-incident information!).
It can also be affected a lot by what platform you are on, the language/framework and server architecture(s). They each have different request-handling concurrency patterns, built-in features, and affordances and standard practices. Node is gonna be really different from Rails. I am curious what platforms were involved here.
I think the reactions are somewhat justified because HTTP/2 was presented as the problem -- or at least it seemed obvious to read the OP in that way.
If the OP had been framed as a cautionary tale about how the devs did not realize their traffic patterns were throttling their requests, the reactions probably would have been more positive.
Turning on HTTP/2 led to a problem for them. That's what they said, that's true, and it's a good warning for others, I don't think it will be at all rare for others to have similar experiences, if they have a high volume. You can't necessarily just turn on HTTP/2 without paying attention to how it will effect your performance characteristics (which you may never have paid much attention to before). The nature of the potential problems that can arise with concurrency/routing/queueing can make them not that obvious to diagnose/debug. Your stack may have been tuned (by you, or by the open source authors/community that established the defaults and best practices for whatever you are using) for pre-HTTP/2 usage patterns.
This is useful notice, and post-mortem. Because I agree some discussion around HTTP/2 seems to have the assumption that it will be basically a transparent freebie.
Some people just like to feel superior. shrug. I was hoping for more interesting discussion about HTTP request concurrency and queueing from those who had been in the trenches, which is what you get from HN technical posts at their best. Instead of a reddit-style battle over who was wrong and who is too smart to make that mistake, which is what you get from HN technical posts at their worst. :)
As with anything involving concurrency and hard-to-predict-exactly usage patterns, it can easily get complicated.
Who else remembers the [Heroku routing debacle of 2013](https://blog.heroku.com/routing_performance_update)?
This stuff ain't easy. Anyone who thinks this would only happen to an unusually "wrong" app, I think, hasn't looked into it seriously. This post was good information, I think it's unfortunate that so much of the discussion seems to be trying to shame the author (making it less likely people in the future will generously share such post-incident information!).
It can also be affected a lot by what platform you are on, the language/framework and server architecture(s). They each have different request-handling concurrency patterns, built-in features, and affordances and standard practices. Node is gonna be really different from Rails. I am curious what platforms were involved here.