您好,登錄后才能下訂單哦!
本系列文章索引《響應式Spring的道法術器》
前情提要 Spring WebFlux快速上手 | Spring WebFlux性能測試 | Spring WebClient性能測試
本文源碼
許多數據庫已陸續推出官方的異步驅動,在Spring Data Reactive中,已經集成了Mongo、Casandra、Redis、CouchDB的異步驅動。
在Spring WebFlux中使用 Reactive Mongo的示例見Spring WebFlux快速上手。
這一節我們通過使用YSCB對MongoDB的同步和異步驅動的性能基準測試,來觀察異步驅動的優勢。
YCSB(Yahoo! Cloud Serving Benchmark)是雅虎開源的一款用于測試各類云服務/NoSQL/鍵值對存儲的性能基準測試工具。YCSB很贊,使用起來很簡單,我們就按照wiki介紹來操作即可。
1)準備YCSB
如果使用Windows,請參考這里來預先安裝必要的軟件和工具。
獲取YCSB有兩種方式,一種是直接下載壓縮包:
curl -O --location https://github.com/brianfrankcooper/YCSB/releases/download/0.12.0/ycsb-0.12.0.tar.gz
tar xfvz ycsb-0.12.0.tar.gz
cd ycsb-0.12.0
另一種是基于源碼構建:
git clone git://github.com/brianfrankcooper/YCSB.git
cd YCSB
mvn clean package
此時就可以使用bin/ycsb
命令來進行性能測試了,運行一下:
usage: bin/ycsb command databse [options]
Commands:
load Execute the load phase
run Execute the transaction phase
shell Interactive mode
...
從上邊的命令幫助可以看到,我們可以運行三種命令:
本節的測試主要用到load和run來進行數據的批量操作,先用load命令加載數據集,然后使用run命令測試數據操作。在YCSB中,測試的工作量由workload文件來定義。我們看到在workloads
下有workload[a-f]幾個配置文件,比如workloada:
# Yahoo! Cloud System Benchmark
# Workload A: Update heavy workload
# Application example: Session store recording recent actions
#
# Read/update ratio: 50/50
# Default data size: 1 KB records (10 fields, 100 bytes each, plus key)
# Request distribution: zipfian
recordcount=1000
operationcount=1000
workload=com.yahoo.ycsb.workloads.CoreWorkload
readallfields=true
readproportion=0.5
updateproportion=0.5
scanproportion=0
insertproportion=0
requestdistribution=zipfian
可見配置文件定義了記錄條數、操作次數、以及不同的操作所占的百分比。比如上邊readproportion
和updateproportion
都是50%,從注釋也可以看出來,這模擬的是一種更新操作比較頻繁的場景,可以模擬Web應用中保存session的場景。
幾個workload的配置通過不同的read/update/scan/insert操作比例來模擬不同的場景。
我們可以通過如下命令對mongo運行基于workloada的load階段的性能測試:
bin/ycsb load mongodb -P workloads/workloada
默認是連接localhost:27017
的mongodb數據庫,如果希望指定數據庫連接信息,可以用-p參數指定:
bin/ycsb load mongodb -P workloads/workloada \
-p "mongodb.url=mongodb://192.168.0.101:27017/ycsb?w=1&maxPoolSize=32&waitQueueMultiple=20"
同時還指定了連接池最大數量和最多等待數量。
當然我們也可以通過命令參數覆蓋workloada文件中的數值,比如:
bin/ycsb load mongodb -P workloads/workloada \
-p "mongodb.url=mongodb://192.168.0.101/ycsb?w=1&maxPoolSize=32&waitQueueMultiple=20" \
-p recordcount=10000 -p operationcount=10000 -threads 20
此外,還用-threads
指定了并發線程數為20。
以上這些是本次測試會用到的內容,其他更多關于YCSB的使用請參考wiki吧。
2)準備測試
本次測試的目標是對比Mongodb同步和異步驅動的性能,簡單起見,從吞吐量和平均操作時長兩個數據來衡量。縱向上,
連接數的變化可以通過mongostat
命令來觀察,如下圖所示:
上邊運行的
mongo-benchmark.sh
是基于bin/ycsb
命令編寫的方便測試的腳本,并輸出一些匯總數據(包括吞吐量和平局操作時長)方便查看,同時也會將每次bin/ycsb
命令輸出的詳細內容保存到output
目錄下的文件中。
腳本可以在代碼庫中找到,如果mongo運行于localhost:27017
,可直接用如下命令執行(在與bin
同目錄下):curl https://raw.githubusercontent.com/get-set/get-reactive/master/ycsb-mongo-shell/mongo-benchmark.sh | bash
圖中上方是對同步驅動和異步驅動各自跑了一次基于workloada的load和run的測試,下方是mongostat
的輸出(每秒輸出一行),從insert
、query
、update
的數字可以找出四個橘×××的框標出的4個階段。通過這些數據我們可以分析出:
insert
的數字增多,加起來是測試預設的30000條數據;類似的run主要是進行基于workload的操作測試,workloada是50/50的read/update,在mongostat的輸出中也有體現。conn
列可以看到數據庫連接個數的變化,對于同步的驅動來說,連接個數會從4個增加到25個,而對于異步的驅動來說,連接個數會從4個增加到7個。通過這種方式,針對不同的線程數,觀察兩種驅動的性能數據并通過mongostat的數據記錄連接數。
一、不限制連接數
為了觀察連接數的變化,先不限制maxPoolSize
(注釋腳本中MAX_POOL_SIZE=8
那一行)。最終結果如下:
圖中,每種顏色的左列和右列分別是同步和異步的數據。直觀起見,我們通過圖表來對比一下:
首先對比一下load階段和run階段的吞吐量(柱越高越好)
可以發現,當線程數達到8個之后,吞吐量的增長趨勢基本消失了,尤其是同步驅動的吞吐量還會隨線程數的繼續增加而略有下降。不知是否跟測試環境為四核八線程的CPU有關系。
然后對比一下INSERT、READ和UPDATE操作的平均時長(柱越低越好)
相對來說,異步驅動能帶來更快的讀寫操作,尤其是應對越來越多的線程的時候。
最后對比一下連接數
連接數的對比更加明顯:對于同步的情況,連接數=線程數+5;而對于異步的情況,連接數幾乎一直保持在7個。沒有對比就沒有傷害呀。
二、限制連接數
下面,將連接數限制為32個,測試一下線程數從30-80的情況下,同步驅動的性能數據:
通過圖表對比:
可見,限制連接數之后,略有改善,但是相比異步驅動來說,仍然有一定差距。
3)結論
首先,需要說明的是,以上并非是以數據庫調優為目的的測試,這里我們只測試了workloada(如果你感興趣可以將腳本中的WORKLOAD
變量修改一下,然后測試其他場景),而且限制連接數為32并沒有特別的依據,對測試的機器來說,32也并非最優的連接數。
通過本節的測試,針對MongoDB驅動我們可以得出以下兩個結論:
上邊我們分別針對Http服務端、Http客戶端以及數據庫進行了同步和異步的測試對比,綜上來看,基于異步非阻塞的響應式應用或驅動能夠以少量且固定的線程應對高并發的請求或調用,對于存在阻塞的場景,能夠比多線程的并發方案提供更高的性能。
響應式和非阻塞并不是總能讓應用跑的更快,況且將代碼構建為非阻塞的執行方式本身還會帶來少量的成本。但是在類似于WEB應用這樣的高并發、少計算且I/O密集的應用中,響應式和非阻塞往往能夠發揮出價值。尤其是微服務應用中,網絡I/O比較多的情況下,效果會更加驚人。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。