一個高性能MySQL proxy(kingshard)的性能測試報告

kingshard的性能測試報告

以前的幾篇blog，給你們分享的都是kingshard（https://github.com/flike/king... )的架構與設計。其實不少人對kingshard的性能也很是關心。最近熱心的網友bigpyer對kingshard作了詳細的性能測試。在此分享一下。

1.測試環境

1.1服務器配置

類別	名稱
OS	雲主機 Ubuntu 14.04 LTS
CPU	Common KVM CPU @ 2.40GHz *4
RAM	8GB
DISK	500GB
kingshard	master分支
Mysql	v5.6.25
Sysbench	v0.5

2.性能需求

1. 測試經過kingshard轉發SQL請求與直連DB發送SQL請求這兩種情形下的性能差距。
2. 測試配置文件中max_conns_limit參數對kingshard的影響，並找出最優值。

3.測試準備工做

3.1 kingshard性能測試環境搭建

利用上述配置的4臺服務器搭建了一個kingshard性能測試環境：

• 服務器A運行着sysbench
• 服務器B運行着kingshard系統
• 服務器C運行着主庫
• 服務器D運行着從庫

四臺服務器處在同一個網段中。具體的拓撲圖以下所示：

有關kingshard系統安裝與配置，請參考文檔安裝kingshard。
有關sysbench v0.5的安裝與命令選項，請參考sysbench。

4.測試過程

執行下面的命令準備測試數據

time sysbench --test=/data/home/test_user/software/sysbench/sysbench/tests/db/oltp.lua \
              --mysql-host=host \
              --mysql-port=9696 \
              --mysql-user=kingshard \
              --mysql-password=kingshard \
              --mysql-db=kingshard \
              --oltp-tables-count=1 \
              --oltp-table-size=1000000 \
              --num-threads=50 \
              --max-requests=1000000 \
              --report-interval=1 \
              prepare

上述命令會建立表sbtest1，數據量爲100w，建表語句以下:

CREATE TABLE `sbtest1` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `k` int(10) unsigned NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  KEY `xid` (`id`),
  KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8 MAX_ROWS=1000000;

4.1 kingshard與直連DB性能比較

利用sysbench測試經過kingshard轉發SQL請求和直連DB發送SQL請求這兩種狀況下，kingshard和Mysql系統的兩項數據指標：QPS和每條SQL請求平均處理時間。
經過sysbench發送四類SQL請求：select、update、insert和delete，場景分別爲只讀、讀寫4比1和只寫。

4.1.1 kingshard與直連DB只讀比較

經過修改host、port執行下面的命令分別測試kingshard轉發SQL或直連DB：

time sysbench --test=/data/home/test_user/software/sysbench/sysbench/tests/db/select.lua \
              --mysql-host=host \
              --mysql-port=9696 \
              --mysql-user=kingshard \
              --mysql-password=kingshard \
              --mysql-db=kingshard \
              --oltp-tables-count=1 \
              --oltp-table-size=1000000 \
              --num-threads=16 \
              --max-requests=1000000 \
              --report-interval=1 \
              --max-time=20 \
              run

利用sysbench測試了併發線程個數不一樣的狀況下，分別執行最大請求次數爲100w的 select操做,經過修改--num-threads能夠得到不一樣併發線程數。
測試鏈接 kingshard 和直連 DB 這兩種狀況下的 QPS（QPS越大，系統性能越好），
測試鏈接 kingshard 和直連 DB 這兩種狀況下的 執行sql平均時延（時延越小，系統性能越好），
每組數據重複測試三次後取平均值，具體數據對好比下表所示：

上表對應的QPS折線圖以下所示：

上表對應的時延折線圖以下所示：

4.1.2 kingshard與直連DB讀寫4:1比較

經過修改host、port執行下面的命令分別測試kingshard轉發SQL或直連DB：

ysbench --test=/data/home/test_user/software/sysbench/sysbench/tests/db/oltp.lua \
              --mysql-host=host \
              --mysql-port=3306 \
              --mysql-user=kingshard \
              --mysql-password=ks \
              --mysql-db=kingshard \
              --oltp-tables-count=1 \
              --oltp-table-size=1000000 \
              --num-threads=16 \
              --max-requests=1000000 \
              --report-interval=1 \
              --max-time=20 \
              run

利用sysbench測試了併發線程個數不一樣的狀況下，分別執行最大請求次數爲100w的 select、update、insert、delete等混合操做,經過修改--num-threads能夠得到不一樣併發線程數。
測試鏈接 kingshard 和直連 DB 這兩種狀況下的 QPS（QPS越大，系統性能越好），
測試鏈接 kingshard 和直連 DB 這兩種狀況下的 執行sql平均時延（時延越小，系統性能越好），
每組數據重複測試三次後取平均值，具體數據對好比下表所示：

上表對應的QPS折線圖以下所示：

上表對應的時延折線圖以下所示：

4.1.3 kingshard與直連DB只寫比較

經過修改host、port執行下面的命令分別測試kingshard轉發SQL或直連DB：

time sysbench --test=/data/home/test_user/software/sysbench/sysbench/tests/db/insert.lua \
              --mysql-host=host \
              --mysql-port=3306 \
              --mysql-user=kingshard \
              --mysql-password=ks \
              --mysql-db=kingshard \
              --oltp-tables-count=1 \
              --oltp-table-size=1000000 \
              --num-threads=16 \
              --max-requests=1000000 \
              --report-interval=1 \
              --max-time=20 \
              run

利用sysbench測試了併發線程個數不一樣的狀況下，分別執行最大請求次數爲100w的insert操做,經過修改--num-threads能夠得到不一樣併發線程數。
測試鏈接 kingshard 和直連 DB 這兩種狀況下的 QPS（QPS越大，系統性能越好），
測試鏈接 kingshard 和直連 DB 這兩種狀況下的 執行sql平均時延（時延越小，系統性能越好），
每組數據重複測試三次後取平均值，具體數據對好比下表所示：

上表對應的QPS折線圖以下所示：

上表對應的時延折線圖以下所示：

**從QPS折線圖能夠看出，當sysbench的併發測試線程較少時，鏈接kingshard和直連DB的QPS差距較大。
這主要是由於當sysbench併發線程少時，kingshard的性能沒有獲得充分的發揮，
sysbench只有不多的線程向kingshard發送請求，此時網絡延遲對QPS的影響是最主要的。**

**當sysbench的併發測試線程較大時，此時kingshard的性能就獲得了充分的發揮，
QPS的對比是鏈接kingshard與直連DB性能對比的真實的反應，網絡延遲對QPS的影響做用就顯得很小了。**

**從以上幾個表個的比例數據來看，經過kingshard轉發select請求時的QPS是直連DB時80%左右，
而update和insert請求對應的QPS則更高一些，至關於直連DB時的85%左右,甚至在併發更高的狀況下直連mysql的性能低於經過kingshards轉發的性能。
由此看來利用kingshard轉發SQL請求帶來的性能降低雖有降低，但徹底能夠接受，甚至高併發場景下kingshard的性能優於直連DB的性能。這也是得益於kingshard在高併發的時候，充分利用了鏈接池的做用，下降了高併發帶來的競爭消耗。**

sysbench併發線程高於512的數據並無給出，由於直連DB已經不能正常完成測試，可是kingshard能夠完成。

4.2 max_conns_limit參數對kingshard性能影響

max_conns_limit 是 kingshard 初始化時建立的與後端mysql長鏈接個數，這個值設置的不一樣對 kingshard 性能也有比較明顯的影響。
咱們猜想max_conns_limit除了與kingshard所在主機CPU核心數有關外還與後端mysql能接納的鏈接數有關。
咱們分別測試將 max_conns_limit 設置爲1六、3二、6四、12八、25六、512時，kingshard轉發select，update和insert三類操做請求時的 QPS，
SQL的混合狀況爲讀寫4比1，且sysbench的不一樣sql分別處於不一樣的事務中，具體對比結果以下所述：

上數測試對應的QPS折線圖以下所示：

從kingshard處理三類SQL操做的QPS對比來看，將max_conns_limit參數設置爲128左右較爲合理, 高於128後經過提升max_conns_limit值並無顯著效果。

max_conns_limit參數值與kingshard所在主機核心數並無必然的聯繫，與後端mysql主機可承受鏈接數關係密切。

5.測試結論

本文主要測試了經過kingshard轉發SQL請求與直連DB發送SQL請求這兩種情形下的性能差距，和max_conns_limit值對kingshard的性能影響。
ks的讀寫性能平都可以達到原生mysql性能的80%，必定條件下能夠達到90%，隨着併發數的增長甚至能超越mysql自己。
ks能夠對mysql造成保護，增長了ks後，db層對外表現出能夠接收更高的併發數，且執行時間長短不一樣的sql使用各自的資源，造成了資源隔離，mysql不會出現性能毛刺。
綜合以上測試結果來看，kingshard性能表現較爲優秀，並無明顯的性能降低。同時在測試中發現kingshard系統屬於CPU密集型任務，相對於磁盤IO和內存佔用率而言，kingshard對CPU消耗顯得最爲明顯，因此建議在部署kingshard的時候須要優先考慮服務器的CPU性能。

6. 公衆號

歡迎關注後端技術快訊公衆號，有關kingshard的最新消息與後端架構設計類的文章，都會在這個公衆號分享。