這是對(duì)MySQL進(jìn)行加密性能測(cè)試的兩篇文章系列之二。在第一篇中，我專門使用MySQL的內(nèi)置的對(duì)SSL的支持來(lái) 做壓力測(cè)試，產(chǎn)生了一些令人驚訝的結(jié)果。當(dāng)然，使用SSL查詢的吞吐性能要比不使用SSL的性能低這也在意料之中，但是我相當(dāng)驚訝的是，主要的性能瓶頸是 花費(fèi)在連接建立的時(shí)間。這個(gè)結(jié)果自然引導(dǎo)更進(jìn)一步的研究。尤其我想要在MySQL內(nèi)置的SSL加密和外部加密技術(shù)——比如SSH通道——之間做一次性能對(duì) 比。我也會(huì)通過(guò)這篇文章明確一些在我上一篇文章的評(píng)論中提出的問(wèn)題。那么，直奔主題吧。。

測(cè)試環(huán)境：

這篇文章中涉及到的測(cè)試環(huán)境一共是四臺(tái)機(jī)器：

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

一些測(cè)試使用的是MySQL5.6.13-community，另一部分是使用Percona Server5.6.13.

外部加密技術(shù)

在這個(gè)測(cè)試中，我在沒(méi)有一個(gè)真正vpn的情況下，用最常用的方式創(chuàng)建一個(gè)站-站連接——即寶刀未老的SSH通道。我沒(méi)有找到足夠的設(shè)備來(lái)組建一個(gè)硬件加速 的VPN，但是這些也足以說(shuō)明問(wèn)題。MySQL/SSL使用的默認(rèn)SSL加密組件是DHE-RSA-AES256-SHA；我們稍微解釋一下，這個(gè)含義是 使用SHA1算法作為我們的hash函數(shù)，RSA作為身份認(rèn)證，256位AES（在CBC模式下，根據(jù)OpenSSL文檔）加密來(lái)實(shí)現(xiàn) Diffie-Hellman密鑰交換。雖然也許并不明顯，通過(guò)OpenSSL是很容易模仿同樣的加密套件的。SSH version2協(xié)議默認(rèn)使用DHE/RSA/SHA1，所以我們需要的就是在建立我們的通道時(shí)指定AES256-CBC加密器，出于所有的意圖和猜測(cè)， 我們會(huì)對(duì)比加密結(jié)果。出于好奇，我們也會(huì)嘗試在SSH通道的CTR模式下使用AES256,因?yàn)檫@能夠加密block，所以理論上將會(huì)稍微快一點(diǎn)，但是最 終結(jié)果，至少在這個(gè)測(cè)試中，這點(diǎn)差別微乎其微。

于這個(gè)測(cè)試的機(jī)器是C機(jī)器(服務(wù)器)和D機(jī)器(客戶端)，這兩個(gè)機(jī)器同在一個(gè)千兆比特的以太網(wǎng)VLAN鏈中，測(cè)試腳本和第一部分的腳本相似，其目的 就是盡可能快的創(chuàng)建100個(gè)連接。每個(gè)測(cè)試配置運(yùn)行10遍，下面的表格列出了平均值和標(biāo)準(zhǔn)差，列出的數(shù)字是每一秒創(chuàng)建的連接數(shù)。同時(shí)，也要注意到這個(gè)特殊 的測(cè)試，所有的密鑰都是4096比特長(zhǎng)，而且所有測(cè)試是在Percona Server 5.6.13上運(yùn)行的。

或者，如果你喜歡圖表的話，下面是圖表的方式。

 很明顯，沒(méi)有加密是最快的，但是通過(guò)SSH隧道創(chuàng)建連接的方式和MySQL本地SSL的方式相比并沒(méi)有損失多少性能。無(wú)論是100 cps或是22 cps都是不現(xiàn)實(shí)的，但我敢打賭對(duì)于大多人來(lái)說(shuō)，每個(gè)獨(dú)立的線程產(chǎn)生470-480 cps的數(shù)目是仍然可以提供服務(wù)的。

高延遲鏈路的連接性能

測(cè)試數(shù)據(jù)在我文章的后邊會(huì)給出。事實(shí)上，SSL連接的穩(wěn)定性受網(wǎng)絡(luò)延遲的影響。 從上述結(jié)果中我們可以看到，在低延遲鏈路，使用SSL對(duì)性能有顯著的影響，那么在廣域網(wǎng)會(huì)怎么樣？有可能一種情況下考慮到了網(wǎng)絡(luò)簡(jiǎn)單往返時(shí)間的延遲,使用 了MySQL內(nèi)置的SSL支持，混合加密就不會(huì)影響太多的性能。 因此，這次測(cè)試中，我拆成了兩個(gè)不同的 Amazon EC2實(shí)例(就是上述的設(shè)備A和設(shè)備B)。 設(shè)備C位于加州北部用來(lái)當(dāng)做client, 這次測(cè)試是在MySQL集群和Percona服務(wù)器下測(cè)試，密鑰大小范圍從0到4096為位。SSL密碼組件使用的是默認(rèn)設(shè)置,測(cè)試腳本和以前一樣需要運(yùn) 行10次，快速創(chuàng)建100個(gè)鏈接，并且每秒刷新連接結(jié)果。當(dāng)然在測(cè)試中，這些原始數(shù)據(jù)是次要的，我們只是想看一下網(wǎng)絡(luò)延遲都SSL性能的影響。

首先, 從 C 到 B (加州北部 到 愛(ài)爾蘭):

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

如我們所料, 很明顯測(cè)試數(shù)據(jù)要比橫跨一個(gè)大陸連接服務(wù)器的數(shù)值低得多，起碼在地理位置上有幾百米的距離吧, 但事實(shí)證明，排除MySQL集群的反應(yīng)， 我們看到實(shí)際上在性能上不會(huì)真的下降那么多。下表比較了從C到B的連接，從C到A的連接。。

以上是幾點(diǎn)意見(jiàn)。首先，如果你服務(wù)器隔著40ms或170ms遠(yuǎn)的時(shí)候1024位的SSL加密對(duì)性能并沒(méi)有 太大的影響。第二，隨著延時(shí)的加長(zhǎng)，由于SSL加密開銷的增加，丟失的連接會(huì)影響。 這很有道理, 特別是在一種常見(jiàn)的情況下 (服務(wù)器在同一個(gè)內(nèi)網(wǎng)，或者通過(guò)TCP連接到同一個(gè)服務(wù)器), 連接的吞吐性能主要由使用不使用SSL來(lái)影響了。 當(dāng)然，MySQL集群4096-bit加密的價(jià)格與Percona服務(wù)器相比，以上這些根本就沒(méi)有任何意義了。有一些特別的手段用來(lái)對(duì)MySQL集群 4096-bit 加密性能提升，但看起來(lái)并沒(méi)有對(duì)Percona服務(wù)器影響多少。我不確定這是一個(gè)很好的假設(shè)，在這兩次測(cè)試中我都可能說(shuō)是一個(gè)PEBCAT。所以，如果其 他人也在測(cè)試，我很好奇的想知道，你是否也得到相同的結(jié)構(gòu)。

原文鏈接：http://www.mysqlperformanceblog.com/2013/11/18/mysql-encryption-performance-revisited/

譯文鏈接：http://www.oschina.net/translate/mysql-encryption-performance-revisited