本系列文章索引《響應式Spring的道法術器》
前情提要 Spring WebFlux快速上手 | Spring WebFlux性能測試 | Spring WebClient性能測試
本文源碼
1.4.4 同步與異步數據庫驅動的性能對比
許多數據庫已陸續推出官方的異步驅動,在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,執行事務,比如更新、查詢等;
- shell,可以交互式地運行測試。
本節的測試主要用到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個階段。通過這些數據我們可以分析出:
- load主要是加載數據集,因此會看到
insert
的數字增多,加起來是測試預設的30000條數據;類似的run主要是進行基於workload的操作測試,workloada是50/50的read/update,在mongostat的輸出中也有體現。 - load階段同步和異步驅動的吞吐量分別爲19801和25554,run階段同步和異步的吞吐量分別爲25706和27675,同步驅動略遜一籌;再觀察insert、read和update操作的平均時長,可以得出同樣的結論。
- 這次測試設置了20個線程對mongo數據庫進行操作,在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驅動我們可以得出以下兩個結論:
- 相對於同步驅動來說,異步驅動在性能方面略勝一籌;
- 在應對大量客戶端線程的情況下,異步驅動能夠以少量而穩定的連接數應對,意味着更少的內存消耗(每個連接消耗stack size的內存空間,默認情況下stack size爲10M)。
1.4.4 總結
上邊我們分別針對Http服務端、Http客戶端以及數據庫進行了同步和異步的測試對比,綜上來看,基於異步非阻塞的響應式應用或驅動能夠以少量且固定的線程應對高併發的請求或調用,對於存在阻塞的場景,能夠比多線程的併發方案提供更高的性能。
響應式和非阻塞並不是總能讓應用跑的更快,況且將代碼構建爲非阻塞的執行方式本身還會帶來少量的成本。但是在類似於WEB應用這樣的高併發、少計算且I/O密集的應用中,響應式和非阻塞往往能夠發揮出價值。尤其是微服務應用中,網絡I/O比較多的情況下,效果會更加驚人。