Hacker News Reader

Comment by jrochkind1 | Hacker News Reader

> For a system which establishes and maintains long-running connections, the initial connection overhead becomes a non-factor, regardless of the encryption strength, but there’s still a rather large performance penalty compared to the unencrypted connection.

A theoretical performance penalty, which, in practice, you just right there told us was a non-factor, right? If you are connection pooling. Which you should be.

But yeah, in just about _any_ sort of application using SSL, if you're not connection pooling your performance is going to be seriously sunk. I demonstrated the same thing ruby HTTP libraries and SSL here: http://bibwild.wordpress.com/2012/04/30/ruby-http-performanc...

MySQL, http, anything -- SSL connection establishing is expensive. If you are making lots of SSL connections, it's going to be expensive. If you can pool and reuse SSL connections, you always always want to, it will make a big difference.

View on HN

> If you are connection pooling. Which you should be.

Plain MySQL connections are exceptionally quick to set up - much more so than many other DB options. For this reason, many people have written code that does not use connection pooling (coughPHPcough), and instead create new connections at whim. This is why it's worth pointing the differences out.

As a point of contrast about the side effects of this connection speed: The standard Python MySQL library does not even offer connection pooling - you would have to write your own or use a ORM that provides pooling. On the other hand, the most oft used PostgreSQL Python library offers connection pooling for free.

Not saying one method is better than the other, but it's quite possible to write a performant solution using MySQL that doesn't pool connections.

In addition, when you are dealing with many thousand application servers and many hundred database connections, the database will not end up happy having to maintain > 10k connections.

So you will end up needing to add a proxy or connect every time. As you indicated, since MySQL connections are so cheap (ie. you can do > 50k per second), it is faster and easier to create a new connection each time.

Not just the database, at those quantities of connections, the OS itself starts to have problems.

One frequently implemented solution is to kill off old idle connections, but you may be surprised at how many pooling solutions don't deal with killed connections well (or force the handling on the application at the wrong layer of abstraction).

> it is faster and easier to create a new connection each time.

Unless you're creating an SSL connection, right?

Did you guys read the same OP I read?

Oh yeah, I didn't mean to imply it's not worth pointing out.

Only that this is more reminder that if you are using SSL, you are going to lose a lot of performance UNLESS you connection pool. Worth pointing out because a lot of people forget or don't realize, but not really MySQL specific (which is fine).

You say it's possible to write a performant solution using MySQL that doesn't pool connections -- sure, if you don't use SSL, right?

I think the "but there's still a rather lager performance penalty" is referring to the measured performance penalty on the established connections. This was pretty significant in the test case, although certainly the unpooled case was much worse.

> A theoretical performance penalty, which, in practice, you just right there told us was a non-factor, right?

Not theoretical at all. Connection pooling will make the initial connection time a non-factor, but it will not make the SSL performance penalty a non-factor.

According to the 1st graph and the data in the table below it, even with connection pooling SSL still reduces performance by 50%-75%. That's a very big penalty.

Hmm, I'm confused what "non-factor" meant to the original author then! 75% performance penalty is a "non-factor", what? Now I'm just confused.

Reply on news.ycombinator.com