Hacker News Reader

Comment by pilif | Hacker News Reader

If I see such bad numbers, usually, before I write a post about it, I try to investigate and share the results of that with the post.

I'll try to reproduce these results tomorrow, but if I had to guess, I'd say ssl_session_cache was left to its default (off) which means that every connection has to do the expensive SSL handshake.

View on HN

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.

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

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?

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.

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!'"

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.

If the config files had been posted, the reader could work out the issues on their own and everybody benefits.

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.

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.

... and here it is:

"nginx does not suck at ssl"

http://news.ycombinator.com/item?id=2759596

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?

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.

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).

IIRC I get pretty awful AB performance with ssl_session_cache on or off.

That said, whilst RPS is low, whilst I'm hammering it with AB it seems to have little problem being responsive in my browser :S

Try adding the -k parameter to ab to use keep alive requests and see if you notice an uptick. If you a generating a new session on each request it doesn't matter if you used the SSL session caching or not in Nginx.

Most of the servers suck at SSL without some sort of caching. Also, properly configured nginx setups have a fair share of keep alives.

Reply on news.ycombinator.com