（9）異步Mongo驅(qū)動的性能測試——響應(yīng)式Spring的道

本系列文章索引《響應(yīng)式Spring的道法術(shù)器》
前情提要 Spring WebFlux快速上手 | Spring WebFlux性能測試 | Spring WebClient性能測試
本文源碼

藁城ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！

1.4.4 同步與異步數(shù)據(jù)庫驅(qū)動的性能對比

許多數(shù)據(jù)庫已陸續(xù)推出官方的異步驅(qū)動，在Spring Data Reactive中，已經(jīng)集成了Mongo、Casandra、redis、CouchDB的異步驅(qū)動。

在Spring WebFlux中使用 Reactive Mongo的示例見Spring WebFlux快速上手。

這一節(jié)我們通過使用YSCB對MongoDB的同步和異步驅(qū)動的性能基準測試，來觀察異步驅(qū)動的優(yōu)勢。

YCSB（Yahoo! Cloud Serving Benchmark）是雅虎開源的一款用于測試各類云服務(wù)/NOSQL/鍵值對存儲的性能基準測試工具。YCSB很贊，使用起來很簡單，我們就按照wiki介紹來操作即可。

1）準備YCSB

如果使用Windows，請參考這里來預(yù)先安裝必要的軟件和工具。

獲取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

另一種是基于源碼構(gòu)建：

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，執(zhí)行數(shù)據(jù)加載，也就是向數(shù)據(jù)庫保存數(shù)據(jù)；
• run，執(zhí)行事務(wù)，比如更新、查詢等；
• shell，可以交互式地運行測試。

本節(jié)的測試主要用到load和run來進行數(shù)據(jù)的批量操作，先用load命令加載數(shù)據(jù)集，然后使用run命令測試數(shù)據(jù)操作。在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

可見配置文件定義了記錄條數(shù)、操作次數(shù)、以及不同的操作所占的百分比。比如上邊readproportion和updateproportion都是50%，從注釋也可以看出來，這模擬的是一種更新操作比較頻繁的場景，可以模擬Web應(yīng)用中保存session的場景。

幾個workload的配置通過不同的read/update/scan/insert操作比例來模擬不同的場景。

我們可以通過如下命令對mongo運行基于workloada的load階段的性能測試：

bin/ycsb load mongodb -P workloads/workloada

默認是連接localhost:27017的mongodb數(shù)據(jù)庫，如果希望指定數(shù)據(jù)庫連接信息，可以用-p參數(shù)指定：

bin/ycsb load mongodb -P workloads/workloada \
-p "mongodb.url=mongodb://192.168.0.101:27017/ycsb?w=1&maxPoolSize=32&waitQueueMultiple=20" 

同時還指定了連接池最大數(shù)量和最多等待數(shù)量。

當然我們也可以通過命令參數(shù)覆蓋workloada文件中的數(shù)值，比如：

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指定了并發(fā)線程數(shù)為20。

以上這些是本次測試會用到的內(nèi)容，其他更多關(guān)于YCSB的使用請參考wiki吧。

2）準備測試

本次測試的目標是對比Mongodb同步和異步驅(qū)動的性能，簡單起見，從吞吐量和平均操作時長兩個數(shù)據(jù)來衡量。縱向上，

• 比較不同數(shù)量的并發(fā)線程對兩個數(shù)據(jù)的影響；
• 觀察測試時的連接數(shù)變化。

連接數(shù)的變化可以通過mongostat命令來觀察，如下圖所示：

上邊運行的mongo-benchmark.sh是基于bin/ycsb命令編寫的方便測試的腳本，并輸出一些匯總數(shù)據(jù)（包括吞吐量和平局操作時長）方便查看，同時也會將每次bin/ycsb命令輸出的詳細內(nèi)容保存到output目錄下的文件中。
腳本可以在代碼庫中找到，如果mongo運行于localhost:27017，可直接用如下命令執(zhí)行（在與bin同目錄下）：

curl https://raw.githubusercontent.com/get-set/get-reactive/master/ycsb-mongo-shell/mongo-benchmark.sh | bash

圖中上方是對同步驅(qū)動和異步驅(qū)動各自跑了一次基于workloada的load和run的測試，下方是mongostat的輸出（每秒輸出一行），從insert、query、update的數(shù)字可以找出四個橘×××的框標出的4個階段。通過這些數(shù)據(jù)我們可以分析出：

• load主要是加載數(shù)據(jù)集，因此會看到insert的數(shù)字增多，加起來是測試預(yù)設(shè)的30000條數(shù)據(jù)；類似的run主要是進行基于workload的操作測試，workloada是50/50的read/update，在mongostat的輸出中也有體現(xiàn)。
• load階段同步和異步驅(qū)動的吞吐量分別為19801和25554，run階段同步和異步的吞吐量分別為25706和27675，同步驅(qū)動略遜一籌；再觀察insert、read和update操作的平均時長，可以得出同樣的結(jié)論。
• 這次測試設(shè)置了20個線程對mongo數(shù)據(jù)庫進行操作，在mongostat輸出的conn列可以看到數(shù)據(jù)庫連接個數(shù)的變化，對于同步的驅(qū)動來說，連接個數(shù)會從4個增加到25個，而對于異步的驅(qū)動來說，連接個數(shù)會從4個增加到7個。

通過這種方式，針對不同的線程數(shù)，觀察兩種驅(qū)動的性能數(shù)據(jù)并通過mongostat的數(shù)據(jù)記錄連接數(shù)。

一、不限制連接數(shù)

為了觀察連接數(shù)的變化，先不限制maxPoolSize（注釋腳本中MAX_POOL_SIZE=8那一行）。最終結(jié)果如下：

圖中，每種顏色的左列和右列分別是同步和異步的數(shù)據(jù)。直觀起見，我們通過圖表來對比一下：

首先對比一下load階段和run階段的吞吐量（柱越高越好）

可以發(fā)現(xiàn)，當線程數(shù)達到8個之后，吞吐量的增長趨勢基本消失了，尤其是同步驅(qū)動的吞吐量還會隨線程數(shù)的繼續(xù)增加而略有下降。不知是否跟測試環(huán)境為四核八線程的CPU有關(guān)系。

然后對比一下INSERT、READ和UPDATE操作的平均時長（柱越低越好）

相對來說，異步驅(qū)動能帶來更快的讀寫操作，尤其是應(yīng)對越來越多的線程的時候。

最后對比一下連接數(shù)

連接數(shù)的對比更加明顯：對于同步的情況，連接數(shù)=線程數(shù)+5；而對于異步的情況，連接數(shù)幾乎一直保持在7個。沒有對比就沒有傷害呀。

二、限制連接數(shù)

下面，將連接數(shù)限制為32個，測試一下線程數(shù)從30-80的情況下，同步驅(qū)動的性能數(shù)據(jù)：

通過圖表對比：

可見，限制連接數(shù)之后，略有改善，但是相比異步驅(qū)動來說，仍然有一定差距。

3）結(jié)論

首先，需要說明的是，以上并非是以數(shù)據(jù)庫調(diào)優(yōu)為目的的測試，這里我們只測試了workloada（如果你感興趣可以將腳本中的WORKLOAD變量修改一下，然后測試其他場景），而且限制連接數(shù)為32并沒有特別的依據(jù)，對測試的機器來說，32也并非最優(yōu)的連接數(shù)。

通過本節(jié)的測試，針對MongoDB驅(qū)動我們可以得出以下兩個結(jié)論：

• 相對于同步驅(qū)動來說，異步驅(qū)動在性能方面略勝一籌；
• 在應(yīng)對大量客戶端線程的情況下，異步驅(qū)動能夠以少量而穩(wěn)定的連接數(shù)應(yīng)對，意味著更少的內(nèi)存消耗（每個連接消耗stack size的內(nèi)存空間，默認情況下stack size為10M）。

1.4.4 總結(jié)

上邊我們分別針對Http服務(wù)端、Http客戶端以及數(shù)據(jù)庫進行了同步和異步的測試對比，綜上來看，基于異步非阻塞的響應(yīng)式應(yīng)用或驅(qū)動能夠以少量且固定的線程應(yīng)對高并發(fā)的請求或調(diào)用，對于存在阻塞的場景，能夠比多線程的并發(fā)方案提供更高的性能。

響應(yīng)式和非阻塞并不是總能讓應(yīng)用跑的更快，況且將代碼構(gòu)建為非阻塞的執(zhí)行方式本身還會帶來少量的成本。但是在類似于WEB應(yīng)用這樣的高并發(fā)、少計算且I/O密集的應(yīng)用中，響應(yīng)式和非阻塞往往能夠發(fā)揮出價值。尤其是微服務(wù)應(yīng)用中，網(wǎng)絡(luò)I/O比較多的情況下，效果會更加驚人。

文章標題：（9）異步Mongo驅(qū)動的性能測試——響應(yīng)式Spring的道
新聞來源：http://www.muchs.cn/article0/gjggio.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、做網(wǎng)站、標簽優(yōu)化、動態(tài)網(wǎng)站、電子商務(wù)、網(wǎng)頁設(shè)計公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)