MySQL 加密的性能测试
这是对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.
外部加密技术
在这个测试中，我在没有一个真正V*N的情况下，用最常用的方式创建一个站-站连接——即宝刀未老的SSH通道。我没有找到足够的设备来组建一个硬 件加速 的V*N，但是这些也足以说明问题。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，所以理论上将会稍微快一点，但是最 终结果，至少在这个测试中，这点差别微乎其微。
| 没有加密 | MySQL+SSL | SSH 隧道(AES256-CBC) | SSH 隧道 (AES256-CTR) |
|---|---|---|---|
| 1001.33 (59.26) | 22.23 (0.1392) | 476.52 (11.87) | 482.02 (13.42) |
于这个测试的机器是C机器(服务器)和D机器(客户端)，这两个机器同在一个千兆比特的以太网VLAN链中，测试脚本和第一部分的脚本相似，其目的 就是尽可能快的创建100个连接。每个测试配置运行10遍，下面的表格列出了平均值和标准差，列出的数字是每一秒创建的连接数。同时，也要注意到这个特殊 的测试，所有的密钥都是4096比特长，而且所有测试是在Percona Server 5.6.13上运行的。
或者，如果你喜欢图表的话，下面是图表的方式。
很明显，没有加密是最快的，但是通过SSH隧道创建连接的方式和MySQL本地SSL的方式相比并没有损失多少性能。无论是100 cps或是22 cps都是不现实的，但我敢打赌对于大多人来说，每个独立的线程产生470-480 cps的数目是仍然可以提供服务的。
高延迟链路的连接性能
测试数据在我文章的后边会给出。事实上，SSL连接的稳定性受网络延迟的影响。 从上述结果中我们可以看到，在低延迟链路，使用SSL对性能有显著的影响，那么在广域网会怎么样？有可能一种情况下考虑到了网络简单往返时间的延迟,使用 了MySQL内置的SSL支持，混合加密就不会影响太多的性能。 因此，这次测试中，我拆成了两个不同的 Amazon EC2实例(就是上述的设备A和设备B)。 设备C位于加州北部用来当做client, 这次测试是在MySQL集群和Percona服务器下测试，密钥大小范围从0到4096为位。SSL密码组件使用的是默认设置,测试脚本和以前一样需要运 行10次，快速创建100个链接，并且每秒刷新连接结果。当然在测试中，这些原始数据是次要的，我们只是想看一下网络延迟都SSL性能的影响。
首先, 从 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
接着, 从 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
如我们所料, 很明显测试数据要比横跨一个大陆连接服务器的数值低得多，起码在地理位置上有几百米的距离吧, 但事实证明，排除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% |
以上是几点意见。首先，如果你服务器隔着40ms或170ms远的时候1024位的SSL加密对性能并没有 太大的影响。第二，随着延时的加长，由于SSL加密开销的增加，丢失的连接会影响。 这很有道理, 特别是在一种常见的情况下 (服务器在同一个内网，或者通过TCP连接到同一个服务器), 连接的吞吐性能主要由使用不使用SSL来影响了。 当然，MySQL集群4096-bit加密的价格与Percona服务器相比，以上这些根本就没有任何意义了。有一些特别的手段用来对MySQL集群 4096-bit 加密性能提升，但看起来并没有对Percona服务器影响多少。我不确定这是一个很好的假设，在这两次测试中我都可能说是一个PEBCAT。所以，如果其 他人也在测试，我很好奇的想知道，你是否也得到相同的结构。
最后思考
先不论MySQL 5.6.13和4096-bit SSL的问题, 我认为这篇文章追逐要表达的和它的前任讲述的也是十分清晰的（译不懂前任的意思）：如果你需要端到端加密你的MySQL传输，MySQL的内置的SSL支 持你使用复制或连接池类的工作量，可能也会满足你的需求，但你的应用是需要频繁的创建和销毁大量的连接,只通过SSH隧道的方式你能减轻加密的负载。