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.

外部加密技術

在這個測試中，我在沒有一個真正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，所以理論上將會稍微快一點，但是最 終結果，至少在這個測試中，這點差別微乎其微。

沒有加密	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。所以，如果其 他人也在測試，我很好奇的想知道，你是否也得到相同的結構。