SSL Performance Overhead in MySQL

http://www.mysqlperformanceblog.com/2013/10/10/mysql-ssl-performance-overhead/

by tdieds • 13 years ago

48 27 13 years ago

jrochkind14• 13 years ago

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.

toast0• 13 years ago

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.

falcolas2• 13 years ago

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.

HarrisonFisk• 13 years ago

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.

jrochkind14• 13 years ago

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?

continuations• 13 years ago

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.

jrochkind14• 13 years ago

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.

PaulHoule• 13 years ago

I hope SSL is a fad.

I haven't once seen an intranet renew it's SSL certificate on time so it means at least once a year there will be a period of a week to six months that you have to click through a warning message.

Google switched the search to SSL and now nobody gets referrers for Google searches anymore.

When Google switched to SSL now I have trouble when I connect to public WiFi networks that want you to agree to something or log in to use the network -- it used to be you got redirected but now search just breaks without a sensible warning message.

tptacek4• 13 years ago

For internal resources, there's no good reason at all to use browser-CA certificates. Just set up your own internal CA (it's like 3 openssl commands), add its certificate to your trust stores, and sign your own certificates.

If you know you're only ever going to have a couple-three boxes using SSL, you can also just use self-signed certificates and a static whitelist. Self-signed certificates don't work at all on the public Internet, but they're just fine for internal resources, as long as you can somehow pin them.

sehrope• 13 years ago

Self-signed certificates don't work at all on the public Internet, but they're just fine for internal resources, as long as you can somehow pin them.

Yes self-signed certificates don't work for web servers/browsers but they work great for *aaS providers.

A lot of DBaaS providers sign their server SSL certificates with an internal self-signed CA (ex: AWS for MySQL RDS[1]). You just need to retrieve the CA certificate over a secure channel (ex: HTTPS) and save it along with the rest of the DB config for your app (user/pass/host/port) so it's pinned.

This is arguably better than using the browser-CA chain as the service provider itself would need to be complicit in compromising it (vs a malicious trusted root issuing a fraudulent trusted cert for the remote server).

[1] http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_M...

viraptor• 13 years ago

add its certificate to your trust stores

If only that was so simple and all software used a common store... Without exceptions like java apps, apps with hardcoded ca_path, scripts which call curl with hardcoded ca_path, etc. On top of that are websockets in FF which will just fail rather than notify you about untrusted certificates. After experiencing that first-hand for a while, I wouldn't recommend this idea. It's the second greatest annoyance after enterprise web proxies.

jakobe3• 13 years ago

add its certificate to your trust stores

I wouldn't install a company CA certificate on my Mac. It would theoretically allow the company to intercept all my SSL connections. I'd rather validate SSL certs for all the intranet servers manually.

trippy_biscuits• 13 years ago

You don't really mean self-signed, do you? I'm a doctor. Here's my diploma. I created and signed it myself. But trust me, I really am a doctor. I hope you really meant that you use an internal CA that issues certs and that you trust that CA instead.

eterm• 13 years ago

So you're angry at google because by them adding security, you now get warned about insecure content rather than being immediately redirected to a site without your choice because your content has been hijacked?

This right here is why security will never be mainstream, because consumers value convenience over the ability for their browser not to run arbitrary code.

Theriac25• 13 years ago

This right here is why security will never be mainstream, because consumers value convenience over the ability for their browser not to run arbitrary code.

You say that as if it's a bad a thing.

icebraining• 13 years ago

Google switched the search to SSL and now nobody gets referrers for Google searches anymore.

You're barking at the wrong tree. Google purposely killed referrers using a intermediate page. If you see this[1] answer on webmasters.SE, they use make the browser pass through a /url redirection page that doesn't have the keywords in the URL. This works in both HTTP and HTTPS.

[1] http://webmasters.stackexchange.com/a/47027

ctz• 13 years ago

I think the grandparent is referencing the fact that Referer headers are not propagated from HTTPS sites to HTTP sites. The rationale was that the HTTPS site might have a secret or otherwise sensitive URL.

This is obviously a tremendously stupid and ineffective design, which is why it fits so well with the rest of browser security design :)

fleitz• 13 years ago

Would be interesting to know what symmetric cipher was used as well as what the key exchange mechanism was. Probably far more important than key size.

I have a feeling it defaulted to DHE+AES256 which is known to be slow.

Also if AES was used, was it configured to use the native AES instructions?

Lots of questions about this benchmark.

SSL Performance Overhead in MySQL

Related Stories