加载中
his is part two on a two-part series on the performance implications of in-flight data encryption with MySQL. In the first part, I focused specifically on the impact of using MySQL’s built-in SSL support with some rather surprising results. Certainly it was expected that query throughput would be lower with SSL than without, but I was rather surprised by the magnitude of the performance hit incurred at connection setup time. These results naturally lended themselves to some further investigation; in particular, I wanted to compare performance differences between MySQL’s built-in SSL encryption facilities and external encryption technologies, such as SSH tunneling. I’ll also be using this post to address a couple of questions posed in the comments on my original article. So, without further ado….

Test Environment

The various tests discussed in this post involved a total of four different machines:

  • Machine A: m1.xlarge EC2 instance (4 vCPU/15GB RAM/Amazon Linux) in US-West-2/Oregon
  • Machine B: m1.xlarge EC2 instance (4 vCPU/15GB RAM/Amazon Linux) in EU-West/Ireland
  • Machine C: Intel Core i7-2600K 3.4GHz (8 HT cores/32GB RAM/CentOS 6.4)
  • Machine D: Intel Core i3-550 3.2GHz (4 HT cores/16GB RAM/CentOS 6.4)

Some tests were conducted with MySQL 5.6.13-community, and other tests were conducted with Percona Server 5.6.13.

这是对MySQL进行加密性能测试的两篇文章系列之二。在第一篇中,我专门使用MySQL的内置的对SSL的支持来做压力测试,产生了一些令人惊讶的结果。当然,使用SSL查询的吞吐性能要比不使用SSL的性能低这也在意料之中,但是我相当惊讶的是,主要的性能瓶颈是花费在连接建立的时间。这个结果自然引导更进一步的研究。尤其我想要在MySQL内置的SSL加密和外部加密技术——比如SSH通道——之间做一次性能对比。我也会通过这篇文章明确一些在我上一篇文章的评论中提出的问题。那么,直奔主题吧。。

测试环境:

这篇文章中涉及到的测试环境一共是四台机器:

  • 机器A:m1.xlarge EC2实例(4核CPU/15GB RAM/Amazon Linux)在US-West-2/Oregon
  • 机器B:m1.xlarge EC2 实例 (4 vCPU/15GB RAM/Amazon Linux) i在 EU-West/Ireland
  • 机器C: Intel Core i7-2600K 3.4GHz (8 HT cores/32GB RAM/CentOS 6.4)
  • 机器D:Intel Core i3-550 3.2GHz (4 HT cores/16GB RAM/CentOS 6.4)

一些测试使用的是MySQL5.6.13-community,另一部分是使用Percona Server5.6.13.

External Encryption Technology

For this test, I looked at one of the most common ways of establishing a site-to-site link in the absence of a “true” VPN – the good old-fashioned SSH tunnel. I don’t have ready access to sufficient gear to set up a hardware-accelerated VPN, but this is enough to illustrate the point. Recall that the default SSL cipher suite used by MySQL/SSL is DHE-RSA-AES256-SHA; if we unpack this a bit, it tells us that we’re using Diffie-Hellman key exchange with SHA1 as our hashing function, RSA for authentication, and encryption with 256-bit AES (in CBC mode, according to the OpenSSL docs). Although perhaps not immediately obvious, this same cipher suite is pretty easy to emulate with OpenSSH. The SSH version 2 protocol uses DHE/RSA/SHA1 by default, so then all we need to do is explicitly specify the AES256-CBC cipher when we’re setting up our tunnel, and we should be, for all intents and purposes, comparing encrypted apples to encrypted apples. For the sake of curiosity, we also try our SSH tunnel with AES256 in CTR mode, which should theoretically be a bit faster due to its ability to encrypt blocks in parallel, but as it turns out, at least for this test, the difference is marginal.

外部加密技术

在这个测试中,我在没有一个真正vpn的情况下,用最常用的方式创建一个站-站连接——即宝刀未老的SSH通道。我没有找到足够的设备来组建一个硬件加速的VPN,但是这些也足以说明问题。MySQL/SSL使用的默认SSL加密组件是DHE-RSA-AES256-SHA;我们稍微解释一下,这个含义是使用SHA1算法作为我们的hash函数,RSA作为身份认证,256位AES(在CBC模式下,根据OpenSSL文档)加密来实现 Diffie-Hellman密钥交换。虽然也许并不明显,通过OpenSSL是很容易模仿同样的加密套件的。SSH version2协议默认使用DHE/RSA/SHA1,所以我们需要的就是在建立我们的通道时指定AES256-CBC加密器,出于所有的意图和猜测,我们会对比加密结果。出于好奇,我们也会尝试在SSH通道的CTR模式下使用AES256,因为这能够加密block,所以理论上将会稍微快一点,但是最终结果,至少在这个测试中,这点差别微乎其微。

The machines used for this test were machines C (server) and D (client), which are on the same VLAN of a gigabit Ethernet link, and the test script in use was similar to that from part 1, wherein we attempt to create 100 connections as fast as possible. Each test configuration was run 10 times, with the averages and standard deviations for each test listed in the table below, and the numbers are given in connections per second. Also, note that for this particular test, all keys used are 4096 bits and tests were run against Percona Server 5.6.13 only.

NO ENCRYPTION MySQL+SSL SSH tunnel (AES256-CBC) SSH tunnel (AES256-CTR)
1001.33 (59.26) 22.23 (0.1392) 476.52 (11.87) 482.02 (13.42)

 

Or, for those of you who like graphics, I think the chart speaks for itself.
connection-throughput2

 

Obviously, not using encryption is still the fastest game in town, but connection throughput over an SSH tunnel doesn’t obliterate performance to anywhere near the same level as using MySQL’s native SSL capability. Going from 1000 cps to 22 cps is potentially unusable, but I’d venture a guess that 470-480 cps in a single thread would still provide serviceable results for most people.

用于这个测试的机器是C机器(服务器)和D机器(客户端),这两个机器同在一个千兆比特的以太网VLAN链中,测试脚本和第一部分的脚本相似,其目的就是尽可能快的创建100个连接。每个测试配置运行10遍,下面的表格列出了平均值和标准差,列出的数字是每一秒创建的连接数。同时,也要注意到这个特殊的测试,所有的密钥都是4096比特长,而且所有测试是在Percona Server 5.6.13上运行的。

没有加密 MySQL+SSL SSH 隧道(AES256-CBC) SSH 隧道 (AES256-CTR)
1001.33 (59.26) 22.23 (0.1392) 476.52 (11.87) 482.02 (13.42)

 

或者,如果你喜欢图表的话,下面是图表的方式。

connection-throughput2

 很明显,没有加密是最快的,但是通过SSH隧道创建连接的方式和MySQL本地SSL的方式相比并没有损失多少性能。无论是100 cps或是22 cps都是不现实的,但我敢打赌对于大多人来说,每个独立的线程产生470-480 cps的数目是仍然可以提供服务的。

Connection Performance over High-Latency Links

Pursuit of data for this test came out of a question left in the comments on my original post; specifically, how the SSL connection penalty is impacted by increasing network latency. We can see from the results above that on a low-latency link, using SSL dramatically impacts performance, but what if we’re doing that connection over a WAN link? It might be the case that if we’re already paying a latency penalty due to simple round-trip time, maybe throwing encryption into the mix won’t hurt that much, even if we do it with MySQL’s built-in SSL support. Thus, for this test, I spun up two different Amazon EC2 instances (machines A and B, described above). Machine C, loacated in Northern California, was used as the client, and this test was conducted both with Community MySQL as well as Percona Server, and with key sizes ranging from zero to 4096 bits. The SSL cipher suite used was the default, and the test script the same as before – run 10 trials, create 100 connections as fast as we can, and report results in connections per second. However, for this test, the raw numbers are somewhat secondary; we’re really just looking to see the impact of network latency on SSL connection performance.

高延迟链路的连接性能

测试数据在我文章的后边会给出。事实上,SSL连接的稳定性受网络延迟的影响。 从上述结果中我们可以看到,在低延迟链路,使用SSL对性能有显著的影响,那么在广域网会怎么样?有可能一种情况下考虑到了网络简单往返时间的延迟,使用了MySQL内置的SSL支持,混合加密就不会影响太多的性能。 因此,这次测试中,我拆成了两个不同的 Amazon EC2实例(就是上述的设备A和设备B)。 设备C位于加州北部用来当做client, 这次测试是在MySQL集群和Percona服务器下测试,密钥大小范围从0到4096为位。SSL密码组件使用的是默认设置,测试脚本和以前一样需要运行10次,快速创建100个链接,并且每秒刷新连接结果。当然在测试中,这些原始数据是次要的,我们只是想看一下网络延迟都SSL性能的影响。

First, from C to B (Northern California to Ireland):
--- ec2-54-220-212-210.eu-west-1.compute.amazonaws.com ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 49228ms
rtt min/avg/max/mdev = 167.851/170.126/177.433/2.289 ms
us_to_ireland_throughput

And next, from C to A (Northern California to Oregon):
--- ec2-54-212-134-221.us-west-2.compute.amazonaws.com ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 49108ms
rtt min/avg/max/mdev = 42.543/44.648/59.994/3.194 ms
us_to_us_throughput

As expected, obviously the raw numbers are much lower for the transcontinental test than they are when connecting to servers that, at least geographically, are only a few hundred miles away, but as it turns out, with the exception of how Community MySQL behaves, which I’ll talk about in a minute, the percentage decrease in performance actually doesn’t really vary by that much. The table below compares connections from C to B with connections from C to A.

首先, 从 C 到 B (加州北部 到 爱尔兰):
--- ec2-54-220-212-210.eu-west-1.compute.amazonaws.com ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 49228ms
rtt min/avg/max/mdev = 167.851/170.126/177.433/2.289 ms
us_to_ireland_throughput

接着, 从 C to A (加州北部 to 俄勒冈州):
--- ec2-54-212-134-221.us-west-2.compute.amazonaws.com ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 49108ms
rtt min/avg/max/mdev = 42.543/44.648/59.994/3.194 ms
us_to_us_throughput

如我们所料, 很明显测试数据要比横跨一个大陆连接服务器的数值低得多,起码在地理位置上有几百米的距离吧, 但事实证明,排除MySQL集群的反应, 我们看到实际上在性能上不会真的下降那么多。下表比较了从C到B的连接,从C到A的连接。。


MySQL 5.6.13 US->EU MySQL 5.6.13 US->US PS 5.6.13 US->EU PS 5.6.13 US->US PS 5.6.13-static US->EU PS 5.6.13-static US->US
1024-bit 34.39% 36.13% 34.59% 35.23% 33.44% 36.31%
2048-bit 37.04% 45.07% 33.91% 38.35% 34.30% 35.40%
4096-bit 51.85% 71.66% 37.06% 43.17% 37.64% 41.66%

 

A few comments on the above. First, at 1024 bits of SSL encryption, it doesn’t make that much difference if you’re 40ms away or 170ms away. Second, as latency decreases, the connection-throughput performance lost due to SSL encryption overhead increases. That makes sense, particularly when we consider that in the base cases (two servers on the same LAN, or connections over a TCP socket to the same server), connection throughput performance is dominated by the use (or not) of SSL. However, the one thing in all of this that doesn’t make sense to me is just how badly community MySQL fares with 4096-bit encryption compared to Percona Server. What’s so special about 4096-bit encryption that tanks the performance of Community MySQL but doesn’t seem to impact Percona Server nearly as much? I don’t have a good answer for this nor even a good hypothesis; if it hadn’t happened on both tests I’d probably have claimed a PEBCAT, but now I’m just not sure. So, if anyone else tries this test, I’d be curious to know if you get the same results.


MySQL 5.6.13 US->EU MySQL 5.6.13 US->US PS 5.6.13 US->EU PS 5.6.13 US->US PS 5.6.13-static US->EU PS 5.6.13-static US->US
1024-bit 34.39% 36.13% 34.59% 35.23% 33.44% 36.31%
2048-bit 37.04% 45.07% 33.91% 38.35% 34.30% 35.40%
4096-bit 51.85% 71.66% 37.06% 43.17% 37.64% 41.66%


以上是几点意见。首先,如果你服务器隔着40ms或170ms远的时候1024位的SSL加密对性能并没有太大的影响。第二,随着延时的加长,由于SSL加密开销的增加,丢失的连接会影响。 这很有道理, 特别是在一种常见的情况下 (服务器在同一个内网,或者通过TCP连接到同一个服务器), 连接的吞吐性能主要由使用不使用SSL来影响了。 当然,MySQL集群4096-bit加密的价格与Percona服务器相比,以上这些根本就没有任何意义了。有一些特别的手段用来对MySQL集群4096-bit 加密性能提升,但看起来并没有对Percona服务器影响多少。我不确定这是一个很好的假设,在这两次测试中我都可能说是一个PEBCAT。所以,如果其他人也在测试,我很好奇的想知道,你是否也得到相同的结构。

Parting Thoughts

Regardless of the anomaly with MySQL 5.6.13 and 4096-bit SSL, I think the primary takeaway from both this post and its predecessor is pretty clear: if you need end-to-end encryption of your MySQL traffic and you’re using replication or a connection-pooling sort of workload, MySQL’s built-in SSL support will probably serve you just fine, but if your application is of the type that requires setting up and tearing down large numbers of connections frequently, you might want to look at offloading that encryption work elsewhere, even if “elsewhere” just means running it through an SSH tunnel.

最后思考

先不论MySQL 5.6.13和4096-bit SSL的问题, 我认为这篇文章追逐要表达的和它的前任讲述的也是十分清晰的(译不懂前任的意思):如果你需要端到端加密你的MySQL传输,MySQL的内置的SSL支持你使用复制或连接池类的工作量,可能也会满足你的需求,但你的应用是需要频繁的创建和销毁大量的连接,只通过SSH隧道的方式你能减轻加密的负载。

返回顶部
顶部