4 ms·

Author here. Let me clarify a couple things I've seen in a lot of the comments. First of all, we do load balance by request, not connections and we do not use

by thayne 8y ago

Author here. Let me clarify a couple things I've seen in a lot of the comments. First of all, we do load balance by request, not connections and we do not use sticky sessions. Secondly, we are aware that our application has underlying problems with large numbers of concurrent requests, which was exposed by using HTTP/2 and we are working on fixing them. The point of the post is not "HTTP/2 sucks because it broke our app". It is "moving to HTTP/2 isn't necessarily as easy as just flipping switch".

otterley 8y ago
Perhaps the title, then, should have been "Why Turning on HTTP/2 Was a Mistake (For Us)" so as not to imply that doing so is a universally bad idea.
- draw_down 8y ago
  It doesn't imply that, be honest.
- geofft 8y ago
  I think it was clear enough - it didn't say "Why Turning On HTTP/2 Is A Mistake" or "Why HTTP/2 Was A Mistake," either which would have implied universal badness. The phrasing had me expecting a specific war story, which is what it ended up being. Besides, I think it's quite reasonable to argue that it's a majority bad idea, even if it's not a universally bad idea. I think many people are probably in the same boat.
  - otterley 8y ago
    Without data, one cannot say either way. What we have before us is a single anecdotal tale. And even that tale, even if you believe it rises to the level of "data," doesn’t provide clear guidance to others, because the details of their stack and capacity are unspecified.
    - titanomachy 8y ago
      Do you mean "anecdotal" rather than "apocryphal"? Apocryphal suggests you have reason to believe this story is untrue.
      - otterley 8y ago
        Yes - thank you for the correction.
    - ricardobeat 8y ago
      Your argument makes sense as a generic statement, but we don’t need a statistically significant sample here. The behaviour described is a logical consequence of how the network and application layers interact and will be seen by anyone with a similar setup, not a natural event that demands more data.
      - deleted 8y ago
        [deleted]
      - otterley 8y ago
        I’m not denying the probability that others similarly situated could experience similar problems. But without the data, there’s no way to know whether the author’s situation would be experienced by a majority of website operators, or even a significant minority.
        geofft 8y ago
        Sure there is—it is my experience as a website operator and as someone familiar with the field of website operation that architectures like theirs are more common than architectures unlike theirs. Professional experience is a (highly compensated) form of gathering data.
        otterley 8y ago
        And I’ve got 20 years of such experience that concludes their architecture is less important than the fact that they simply ran out of peak capacity; and that we do not know how many sites operate so near capacity for us to conclusively determine whether a majority of them are at risk. Who’s right?
  - intertextuality 8y ago
    There's little difference in using "why turning on http/2 (is/was) a mistake". Is is stronger, but both imply that there is/was something wrong with it, to the point of writing an article about it. A better title would be "why turning on http/2 was a mistake (for us)." The current one implies failure due to http/2 itself, and not architectural decisions that lead to making the upgrade to http/2 not as easy as imagined.
- macspoofing 8y ago
  It's a good thing people don't just read the headline.. Right?
  - lucisferre 8y ago
    I mean isn't that why we come to HN, to read and discuss headlines?
    - otterley 8y ago
      Ideally, we’d be discussing the content, not the headlines. And ideally the headlines reflect the content, but history shows that is often not the case. Self-aggrandizement and sensational headlines are par for the course for HN nowadays.
- floatingatoll 8y ago
  That’s implied by the post context, and doesn’t resolve the clickbait nature of the missing “Why”. A more correct title would be: “Turning on HTTP/2 increased request burstiness, breaking our application”
  - otterley 8y ago
    It’s not even clear that it broke their application. They simply didn’t allocate enough compute resources to it AFAICT.
    - floatingatoll 8y ago
      "Broke" is commonly used to describe an interruption in application service to end users. If one enables HTTP/2 and production goes down, someone could quite rightly point out that "you performed action A, causing impact B, which broke the app". Determining in root cause analysis that impact B stemmed from underprovisioned peak demand compute resources in no way contradicts the usage of "broke".
      - otterley 8y ago
        That’s not usually the way the term is used internally in practice when you exhaust your capacity, in my experience. It’s more typically used when sites start crashing or returning invalid data due to bugs in the software.
        judge2020 8y ago
        Internally, no. When dealing with incident response, you would not just say "http2 broke it", but as a quick way to describe the issue, it's fair to say "http2 broke our application" as it prevented access to the service.
        zimpenfish 8y ago
        In my experience (adding 25 years of anecdata to the pile) running out of capacity which leads to interruptions in service to users will quickly get you a lot of emails about things being "broke" from both users and internal teams.
- da_chicken 8y ago
  Titles aren't supposed to be comprehensive, and rhetoric in general is significantly less effective if you spend all your time carving out exceptions for differing opinions. Titles are supposed to get you to read the article and give you an idea of the topic. If you read the article, it's clearly discussing the problems that they experienced. I don't see why they need to qualify everything they said with IMO, IMX, for us, in our case, etc. At no point in the article itself does the author assert that their experience will match yours. Quite the opposite; the author goes out of their way to describe their environment and why they were impacted in particular. At some point, the reader needs to assume that the author is only talking about what they're talking about -- their specific situation -- and not asserting some omnipotent will to obliterate your opinion or disagreement because they didn't add "(For Us)" to the title. In other words, complaining that the title isn't explicitly subjective is probably the weakest criticism you could make because, at best, it's a criticism of a rhetorical style rather than any criticism of the substance of the piece. Not only is the reader more than capable of coming to that decision, not only can they be expected to do so if they actually read it, you're not actually disagreeing with anything the article says nor are you presenting any alternative opinion and you're certainly not providing any contrary evidence. You're disagreeing, but there's no substance to your disagreement. "I had to read the article to understand what it was actually about," is not really a criticism!
  - otterley 8y ago
    > rhetoric in general is significantly less effective if you spend all your time carving out exceptions for differing opinions HN is aimed at an engineering audience, not a political one. I, and others like me (at least used to) come here for enlightenment, not rhetoric. Moreover, the article itself is not argumentative. It didn’t need to be spiced up with a provocative title to be valuable.
    - da_chicken 8y ago
      Rhetoric is not just writing persuasively. Rhetoric is about communicating effectively. Saying you don't need rhetoric because you're an engineer is like saying you don't care if people think you're telling the truth because you're an engineer. It's absurd. It doesn't matter if you're writing an opinion piece, a political piece, or a technical piece, if you want to structure your writing in a way that can be easily read, understood, and followed, you want to obey the principles of rhetoric.
- manojlds 8y ago
  Isn't it always in some context and scope?
- bryanrasmussen 8y ago
  Was a mistake, given common English usage, implies a mistake in the individual case - that is to say "Was a mistake" means "Was a mistake for us". On the other hand would be a mistake implies a mistake for at least the reader, and commonly is interpreted in the most general application available.
bmm6o 8y ago
I'm familiar with your app, but only as a casual user. It's quite nice, btw. I'm having some trouble picturing this. Can you add some numbers? Like, how many nodes is the load balancer spreading the load over, and how many simultaneous requests were you seeing from a browser?

by thayne 8y ago

otterley 8y ago

Perhaps the title, then, should have been "Why Turning on HTTP/2 Was a Mistake (For Us)" so as not to imply that doing so is a universally bad idea.

draw_down 8y ago
It doesn't imply that, be honest.
geofft 8y ago
I think it was clear enough - it didn't say "Why Turning On HTTP/2 Is A Mistake" or "Why HTTP/2 Was A Mistake," either which would have implied universal badness. The phrasing had me expecting a specific war story, which is what it ended up being. Besides, I think it's quite reasonable to argue that it's a majority bad idea, even if it's not a universally bad idea. I think many people are probably in the same boat.
- otterley 8y ago
  Without data, one cannot say either way. What we have before us is a single anecdotal tale. And even that tale, even if you believe it rises to the level of "data," doesn’t provide clear guidance to others, because the details of their stack and capacity are unspecified.
  - titanomachy 8y ago
    Do you mean "anecdotal" rather than "apocryphal"? Apocryphal suggests you have reason to believe this story is untrue.
    - otterley 8y ago
      Yes - thank you for the correction.
  - ricardobeat 8y ago
    Your argument makes sense as a generic statement, but we don’t need a statistically significant sample here. The behaviour described is a logical consequence of how the network and application layers interact and will be seen by anyone with a similar setup, not a natural event that demands more data.
    - deleted 8y ago
      [deleted]
    - otterley 8y ago
      I’m not denying the probability that others similarly situated could experience similar problems. But without the data, there’s no way to know whether the author’s situation would be experienced by a majority of website operators, or even a significant minority.
      - geofft 8y ago
        Sure there is—it is my experience as a website operator and as someone familiar with the field of website operation that architectures like theirs are more common than architectures unlike theirs. Professional experience is a (highly compensated) form of gathering data.
        otterley 8y ago
        And I’ve got 20 years of such experience that concludes their architecture is less important than the fact that they simply ran out of peak capacity; and that we do not know how many sites operate so near capacity for us to conclusively determine whether a majority of them are at risk. Who’s right?
- intertextuality 8y ago
  There's little difference in using "why turning on http/2 (is/was) a mistake". Is is stronger, but both imply that there is/was something wrong with it, to the point of writing an article about it. A better title would be "why turning on http/2 was a mistake (for us)." The current one implies failure due to http/2 itself, and not architectural decisions that lead to making the upgrade to http/2 not as easy as imagined.
macspoofing 8y ago
It's a good thing people don't just read the headline.. Right?
- lucisferre 8y ago
  I mean isn't that why we come to HN, to read and discuss headlines?
  - otterley 8y ago
    Ideally, we’d be discussing the content, not the headlines. And ideally the headlines reflect the content, but history shows that is often not the case. Self-aggrandizement and sensational headlines are par for the course for HN nowadays.
floatingatoll 8y ago
That’s implied by the post context, and doesn’t resolve the clickbait nature of the missing “Why”. A more correct title would be: “Turning on HTTP/2 increased request burstiness, breaking our application”
- otterley 8y ago
  It’s not even clear that it broke their application. They simply didn’t allocate enough compute resources to it AFAICT.
  - floatingatoll 8y ago
    "Broke" is commonly used to describe an interruption in application service to end users. If one enables HTTP/2 and production goes down, someone could quite rightly point out that "you performed action A, causing impact B, which broke the app". Determining in root cause analysis that impact B stemmed from underprovisioned peak demand compute resources in no way contradicts the usage of "broke".
    - otterley 8y ago
      That’s not usually the way the term is used internally in practice when you exhaust your capacity, in my experience. It’s more typically used when sites start crashing or returning invalid data due to bugs in the software.
      - judge2020 8y ago
        Internally, no. When dealing with incident response, you would not just say "http2 broke it", but as a quick way to describe the issue, it's fair to say "http2 broke our application" as it prevented access to the service.
      - zimpenfish 8y ago
        In my experience (adding 25 years of anecdata to the pile) running out of capacity which leads to interruptions in service to users will quickly get you a lot of emails about things being "broke" from both users and internal teams.
da_chicken 8y ago
Titles aren't supposed to be comprehensive, and rhetoric in general is significantly less effective if you spend all your time carving out exceptions for differing opinions. Titles are supposed to get you to read the article and give you an idea of the topic. If you read the article, it's clearly discussing the problems that they experienced. I don't see why they need to qualify everything they said with IMO, IMX, for us, in our case, etc. At no point in the article itself does the author assert that their experience will match yours. Quite the opposite; the author goes out of their way to describe their environment and why they were impacted in particular. At some point, the reader needs to assume that the author is only talking about what they're talking about -- their specific situation -- and not asserting some omnipotent will to obliterate your opinion or disagreement because they didn't add "(For Us)" to the title. In other words, complaining that the title isn't explicitly subjective is probably the weakest criticism you could make because, at best, it's a criticism of a rhetorical style rather than any criticism of the substance of the piece. Not only is the reader more than capable of coming to that decision, not only can they be expected to do so if they actually read it, you're not actually disagreeing with anything the article says nor are you presenting any alternative opinion and you're certainly not providing any contrary evidence. You're disagreeing, but there's no substance to your disagreement. "I had to read the article to understand what it was actually about," is not really a criticism!
- otterley 8y ago
  > rhetoric in general is significantly less effective if you spend all your time carving out exceptions for differing opinions HN is aimed at an engineering audience, not a political one. I, and others like me (at least used to) come here for enlightenment, not rhetoric. Moreover, the article itself is not argumentative. It didn’t need to be spiced up with a provocative title to be valuable.
  - da_chicken 8y ago
    Rhetoric is not just writing persuasively. Rhetoric is about communicating effectively. Saying you don't need rhetoric because you're an engineer is like saying you don't care if people think you're telling the truth because you're an engineer. It's absurd. It doesn't matter if you're writing an opinion piece, a political piece, or a technical piece, if you want to structure your writing in a way that can be easily read, understood, and followed, you want to obey the principles of rhetoric.
manojlds 8y ago
Isn't it always in some context and scope?
bryanrasmussen 8y ago
Was a mistake, given common English usage, implies a mistake in the individual case - that is to say "Was a mistake" means "Was a mistake for us". On the other hand would be a mistake implies a mistake for at least the reader, and commonly is interpreted in the most general application available.

bmm6o 8y ago

I'm familiar with your app, but only as a casual user. It's quite nice, btw. I'm having some trouble picturing this. Can you add some numbers? Like, how many nodes is the load balancer spreading the load over, and how many simultaneous requests were you seeing from a browser?