7 ms·

Sigh. Sometimes posts like these make me want to go back to academia (it's not perfect, but they generally believe in this little thing called rigor). From TFA

by yid 15y ago

Sigh. Sometimes posts like these make me want to go back to academia (it's not perfect, but they generally believe in this little thing called rigor). From TFA: I tested nginx as a proxy, serving static files, and serving nginx-generated redirects. I tried changing all the relevant ssl parameters I could find. All setups resulted in the same SSL performance from nginx. I even tried the setup on more than one server (the other server was quad-core nginx got up to 75 requests per second). So "all the relevant ssl parameters I could find", no details about what those involve, and the surprising result that it made no difference. In the same situation, I might think I was doing something wrong... And then this overarching statement: Never let nginx listen for SSL connections itself.

palish 15y ago
But... that would take work! And he only works four hours a week. </tonguecheek>
seiji 15y ago
Rigor is an interesting point. Do we prefer to have a flawed, but slightly useful, post now - or - do we prefer to wait a month or two for a squeaky clean post with all issues worked out?
- vog 15y ago
  Why not doing both? First a small article about the surprising phenomenon, which announces a more thorough analysis next week. That way, it is possible to get some initial feedback and maybe even some good hints that help speeding up the analysis. In the best case, the announced analysis could become a collaboration by multiple authors.
  - seiji 15y ago
    As Randy says: "The best way to get tech support online isn't to ask for help -- just visit a chat room and declare 'Linux sucks! It can't do X!'"
    - btilly 15y ago
      That reminds me of the old trick of asking a reasonable question. Then getting a friend to give a wrong answer to that. The real answer is likely to be somewhere in the flood of corrections that you see.
- eli 15y ago
  If the config files had been posted, the reader could work out the issues on their own and everybody benefits.
- whirlycott1 15y ago
  In two years, people will still be saying "nginx + ssl = bad" because of this post even though the problem may well be fully addressed. Google will continue to surface this article even though it may be totally wrong at some future date. That sucks.
  - vog 15y ago
    If it was really that easy to spread this questionable message for years, it would be as easy to spread other articles as well. So it wouldn't need more than a few articles, like "nginx + ssl = works like a charm", or "nginx has better SSL support than Apache". It would not matter whether those were actually correct, just a single article of questionable quality would be sufficient.
    - vog 15y ago
      ... and here it is: "nginx does not suck at ssl" http://news.ycombinator.com/item?id=2759596 http://news.ycombinator.com/item?id=2759596
- va_coder 15y ago
  I agree. What if we all waited until 2008 for an academic to publish a 30 page paper about Ruby and Python and how they can be useful for building web apps?
vacri 15y ago
Academics share and discuss findings in casual terms before formal publishing all the time. Two academics meeting over coffee aren't going to demand the rigor you get with a published article.
- _delirium 15y ago
  That's true, but the "damage" tends to be limited, because it's shared in person with a handful of people who understand the preliminary nature of the results--- not potentially tens of thousands of people clicking on the front page of Hacker News, who see a very definitive-sounding statement ("Nginx sucks at SSL"). I do think academics overcorrect on this, and should share more early results, possibly via things like blog posts (this is slowly starting to happen). But erring in the opposite direction is also quite common among tech bloggers. In particular, if you're going to publish anything that looks vaguely like a benchmark, it might be worth taking at least a few days to check out possible problems before sending it out into the world (not months or anything, but a few days).

by yid 15y ago

palish 15y ago

But... that would take work! And he only works four hours a week. </tonguecheek>

seiji 15y ago

Rigor is an interesting point. Do we prefer to have a flawed, but slightly useful, post now - or - do we prefer to wait a month or two for a squeaky clean post with all issues worked out?

vog 15y ago
Why not doing both? First a small article about the surprising phenomenon, which announces a more thorough analysis next week. That way, it is possible to get some initial feedback and maybe even some good hints that help speeding up the analysis. In the best case, the announced analysis could become a collaboration by multiple authors.
- seiji 15y ago
  As Randy says: "The best way to get tech support online isn't to ask for help -- just visit a chat room and declare 'Linux sucks! It can't do X!'"
  - btilly 15y ago
    That reminds me of the old trick of asking a reasonable question. Then getting a friend to give a wrong answer to that. The real answer is likely to be somewhere in the flood of corrections that you see.
eli 15y ago
If the config files had been posted, the reader could work out the issues on their own and everybody benefits.
whirlycott1 15y ago
In two years, people will still be saying "nginx + ssl = bad" because of this post even though the problem may well be fully addressed. Google will continue to surface this article even though it may be totally wrong at some future date. That sucks.
- vog 15y ago
  If it was really that easy to spread this questionable message for years, it would be as easy to spread other articles as well. So it wouldn't need more than a few articles, like "nginx + ssl = works like a charm", or "nginx has better SSL support than Apache". It would not matter whether those were actually correct, just a single article of questionable quality would be sufficient.
  - vog 15y ago
    ... and here it is: "nginx does not suck at ssl" http://news.ycombinator.com/item?id=2759596 http://news.ycombinator.com/item?id=2759596
va_coder 15y ago
I agree. What if we all waited until 2008 for an academic to publish a 30 page paper about Ruby and Python and how they can be useful for building web apps?

vacri 15y ago

Academics share and discuss findings in casual terms before formal publishing all the time. Two academics meeting over coffee aren't going to demand the rigor you get with a published article.

_delirium 15y ago
That's true, but the "damage" tends to be limited, because it's shared in person with a handful of people who understand the preliminary nature of the results--- not potentially tens of thousands of people clicking on the front page of Hacker News, who see a very definitive-sounding statement ("Nginx sucks at SSL"). I do think academics overcorrect on this, and should share more early results, possibly via things like blog posts (this is slowly starting to happen). But erring in the opposite direction is also quite common among tech bloggers. In particular, if you're going to publish anything that looks vaguely like a benchmark, it might be worth taking at least a few days to check out possible problems before sending it out into the world (not months or anything, but a few days).