建站
咨詢
售后
建站咨詢
新聞中心
這是對MySQL進(jìn)行加密性能測試的兩篇文章系列之二。在第一篇中，我專門使用MySQL的內(nèi)置的對SSL的支持來 做壓力測試，產(chǎn)生了一些令人驚訝的結(jié)果。當(dāng)然，使用SSL查詢的吞吐性能要比不使用SSL的性能低這也在意料之中，但是我相當(dāng)驚訝的是，主要的性能瓶頸是 花費在連接建立的時間。這個結(jié)果自然引導(dǎo)更進(jìn)一步的研究。尤其我想要在MySQL內(nèi)置的SSL加密和外部加密技術(shù)——比如SSH通道——之間做一次性能對 比。我也會通過這篇文章明確一些在我上一篇文章的評論中提出的問題。那么，直奔主題吧。。
南鄭網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站開發(fā)等網(wǎng)站項目制作，到程序開發(fā)，運營維護(hù)。成都創(chuàng)新互聯(lián)成立于2013年到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)。
測試環(huán)境：
這篇文章中涉及到的測試環(huán)境一共是四臺機(jī)器：
- 機(jī)器A：m1.xlarge EC2實例（4核CPU/15GB RAM/Amazon Linux）在US-West-2/Oregon
- 機(jī)器B：m1.xlarge EC2 實例 (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)
一些測試使用的是MySQL5.6.13-community，另一部分是使用Percona Server5.6.13.
外部加密技術(shù)
在這個測試中，我在沒有一個真正vpn的情況下，用最常用的方式創(chuàng)建一個站-站連接——即寶刀未老的SSH通道。我沒有找到足夠的設(shè)備來組建一個硬件加速 的VPN，但是這些也足以說明問題。MySQL/SSL使用的默認(rèn)SSL加密組件是DHE-RSA-AES256-SHA；我們稍微解釋一下，這個含義是 使用SHA1算法作為我們的hash函數(shù)，RSA作為身份認(rèn)證，256位AES（在CBC模式下，根據(jù)OpenSSL文檔）加密來實現(xiàn) Diffie-Hellman密鑰交換。雖然也許并不明顯，通過OpenSSL是很容易模仿同樣的加密套件的。SSH version2協(xié)議默認(rèn)使用DHE/RSA/SHA1，所以我們需要的就是在建立我們的通道時指定AES256-CBC加密器，出于所有的意圖和猜測， 我們會對比加密結(jié)果。出于好奇，我們也會嘗試在SSH通道的CTR模式下使用AES256,因為這能夠加密block，所以理論上將會稍微快一點，但是最 終結(jié)果，至少在這個測試中，這點差別微乎其微。
|
|
|
|
|---|---|---|---|
|
|
|
|
于這個測試的機(jī)器是C機(jī)器(服務(wù)器)和D機(jī)器(客戶端)，這兩個機(jī)器同在一個千兆比特的以太網(wǎng)VLAN鏈中，測試腳本和第一部分的腳本相似，其目的 就是盡可能快的創(chuàng)建100個連接。每個測試配置運行10遍，下面的表格列出了平均值和標(biāo)準(zhǔn)差，列出的數(shù)字是每一秒創(chuàng)建的連接數(shù)。同時，也要注意到這個特殊 的測試，所有的密鑰都是4096比特長，而且所有測試是在Percona Server 5.6.13上運行的。
或者，如果你喜歡圖表的話，下面是圖表的方式。
很明顯，沒有加密是最快的，但是通過SSH隧道創(chuàng)建連接的方式和MySQL本地SSL的方式相比并沒有損失多少性能。無論是100 cps或是22 cps都是不現(xiàn)實的，但我敢打賭對于大多人來說，每個獨立的線程產(chǎn)生470-480 cps的數(shù)目是仍然可以提供服務(wù)的。
高延遲鏈路的連接性能
測試數(shù)據(jù)在我文章的后邊會給出。事實上，SSL連接的穩(wěn)定性受網(wǎng)絡(luò)延遲的影響。 從上述結(jié)果中我們可以看到，在低延遲鏈路，使用SSL對性能有顯著的影響，那么在廣域網(wǎng)會怎么樣？有可能一種情況下考慮到了網(wǎng)絡(luò)簡單往返時間的延遲,使用 了MySQL內(nèi)置的SSL支持，混合加密就不會影響太多的性能。 因此，這次測試中，我拆成了兩個不同的 Amazon EC2實例(就是上述的設(shè)備A和設(shè)備B)。 設(shè)備C位于加州北部用來當(dāng)做client, 這次測試是在MySQL集群和Percona服務(wù)器下測試，密鑰大小范圍從0到4096為位。SSL密碼組件使用的是默認(rèn)設(shè)置,測試腳本和以前一樣需要運 行10次，快速創(chuàng)建100個鏈接，并且每秒刷新連接結(jié)果。當(dāng)然在測試中，這些原始數(shù)據(jù)是次要的，我們只是想看一下網(wǎng)絡(luò)延遲都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
如我們所料, 很明顯測試數(shù)據(jù)要比橫跨一個大陸連接服務(wù)器的數(shù)值低得多，起碼在地理位置上有幾百米的距離吧, 但事實證明，排除MySQL集群的反應(yīng)， 我們看到實際上在性能上不會真的下降那么多。下表比較了從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% |
以上是幾點意見。首先，如果你服務(wù)器隔著40ms或170ms遠(yuǎn)的時候1024位的SSL加密對性能并沒有 太大的影響。第二，隨著延時的加長，由于SSL加密開銷的增加，丟失的連接會影響。 這很有道理, 特別是在一種常見的情況下 (服務(wù)器在同一個內(nèi)網(wǎng)，或者通過TCP連接到同一個服務(wù)器), 連接的吞吐性能主要由使用不使用SSL來影響了。 當(dāng)然，MySQL集群4096-bit加密的價格與Percona服務(wù)器相比，以上這些根本就沒有任何意義了。有一些特別的手段用來對MySQL集群 4096-bit 加密性能提升，但看起來并沒有對Percona服務(wù)器影響多少。我不確定這是一個很好的假設(shè)，在這兩次測試中我都可能說是一個PEBCAT。所以，如果其 他人也在測試，我很好奇的想知道，你是否也得到相同的結(jié)構(gòu)。
最后思考
先不論MySQL 5.6.13和4096-bit SSL的問題, 我認(rèn)為這篇文章追逐要表達(dá)的和它的前任講述的也是十分清晰的（譯不懂前任的意思）：如果你需要端到端加密你的MySQL傳輸，MySQL的內(nèi)置的SSL支持你使用復(fù)制或連接池類的工作量，可能也會滿足你的需求，但你的應(yīng)用是需要頻繁的創(chuàng)建和銷毀大量的連接,只通過SSH隧道的方式你能減輕加密的負(fù)載。
本文標(biāo)題：MySQL加密的性能測試
分享網(wǎng)址：http://www.dlmjj.cn/article/cojoeoi.html
