高錦博 嚴(yán) 悍 李雪飛 周亞茹

（南京理工大學(xué)計算機科學(xué)與技術(shù)學(xué)院 南京 210094）

1 引言

性能低下是區(qū)塊鏈的普遍問題，Hyperledger Fabric［1］亦是如此。Fabric支持通過 CLI、SDK［2］等方式來訪問Fabric區(qū)塊鏈網(wǎng)絡(luò)［3］。其中的Fabric SDK Node［4］利用 NodeJs的異步非阻塞特點［5］作為Fabric的客戶端［6］來訪問Fabric網(wǎng)絡(luò)，為應(yīng)用提供服務(wù)，作為應(yīng)用的服務(wù)器，它的負載能力是一個重要的關(guān)注點。負載測試［7］是通過不斷增加用戶請求并發(fā)數(shù)，測試不同負載條件下應(yīng)用服務(wù)器對客戶端請求的響應(yīng)時間、吞吐率等數(shù)據(jù)，研究應(yīng)用服務(wù)器所能提供的最大負載能力［8］。本文主要研究Fabric SDK Node作為Fabric網(wǎng)絡(luò)客戶端的負載測試。

文獻［9］通過設(shè)計測試工具、方法，對Fabric進行測試，給出了測試數(shù)據(jù)，但并非是基于Fabric SDK Node訪問網(wǎng)絡(luò)的負載測試以及測試工具。Hyperledger Caliper是一個區(qū)塊鏈測試工具，支持Fabric 1.1版本的測試［10］，該工具通過改變交易提交速率，進行性能測試。但是目前Fabric已經(jīng)更新至1.3版本［11］，該工具的適用性還待測試。綜上，目前缺乏支持Fabric 1.3，并且基于Fabric SDK Node客戶端的負載測試工具。

本文針對Fabric 1.3，基于Fabric SDK Node設(shè)計一個客戶端負載測試工具，通過改變并發(fā)數(shù)施加不同并發(fā)負載，并測試不同區(qū)塊大?。疵總€區(qū)塊包含的交易數(shù)量），區(qū)塊鏈的讀寫性能，分析不同區(qū)塊大小、并發(fā)數(shù)和性能之間的關(guān)系。

2 方案設(shè)計

2.1 架構(gòu)

測試工具以及區(qū)塊鏈網(wǎng)絡(luò)的架構(gòu)如圖1。

圖1 測試工具架構(gòu)圖

1）在監(jiān)控端通過指令調(diào)用測試工具。在調(diào)用測試工具的時候需要指定讀寫命令以及并發(fā)次數(shù)。

2）測試模塊包含：負載發(fā)生器、數(shù)據(jù)采集、數(shù)據(jù)分析統(tǒng)計以及記錄模塊。

（1）負載發(fā)生器：根據(jù)監(jiān)控端所傳參數(shù)，通過NodeJS異步編程，并發(fā)執(zhí)行交易請求，施加負載；

（2）數(shù)據(jù)采集：在所有交易異步并發(fā)執(zhí)行的過程中，采集交易基本數(shù)據(jù)（見章節(jié)2.2），便于分析統(tǒng)計；

（3）數(shù)據(jù)分析統(tǒng)計及記錄：根據(jù)采集到的交易的基本數(shù)據(jù)，計算相關(guān)性能指標(biāo)（見章節(jié)2.2），如平均響應(yīng)時間、吞吐率等數(shù)據(jù)；同時將所有數(shù)據(jù)記錄在本地excel文件中，以便根據(jù)不同需求進行數(shù)據(jù)再次分析。

3）基礎(chǔ)交易模塊：交易模塊一般分為兩類，invoke寫入交易和query查詢交易。測試工具包含這兩種交易模塊的測試。

4）Fabric SDK Node：測試模塊以及基礎(chǔ)交易模塊都是通過Fabric SDK Node來對Fabric區(qū)塊鏈網(wǎng)絡(luò)進行訪問。

2.2 測試方法及度量指標(biāo)

該測試工具在進行一次并發(fā)測試的過程中，對于測試并發(fā)壓力的施加以及完成過程，分為三個階段：加載期、負載期、卸載期。如圖2所示。

圖2 測試階段

1）加載期：從t0到t1階段，根據(jù)提交的參數(shù)提交n個交易，在到t1時刻加載完成最后一個交易，每個交易的起始時間都在［t0，t1］之間；

2）負載期：從t1到t2階段，t2時刻第一個交易完成，即最快的交易完成。系統(tǒng)在此期間被加載所有交易，并發(fā)執(zhí)行交易，但是沒有一個交易完成。

3）卸載期：從t2到t3階段，之前提交的所有交易開始陸續(xù)完成，t2時刻第一個交易完成，t3時刻最后一個交易完成，即全部交易完成。

在進行并發(fā)數(shù)為n的測試過程中，需要采集交易基本數(shù)據(jù)：

1）第i個交易的起始時間bi；

2）第i個交易的完成時間ei；

3）所有交易的起始時間t0；

4）交易加載時間t1；

5）首次交易吐出時間t2；

6）所有交易完成時間t3。

根據(jù)基本數(shù)據(jù)計算以下相關(guān)性能指標(biāo)：

1）吞吐率TPS［12］（Transaction Per Second）：指從交易請求開始到所有交易完成，每秒完成的平均交易數(shù)量。

2）響應(yīng)時間RT（Response Time）：指從交易提交到完成所耗費的時間，根據(jù)交易的起始時間bi和完成時間ei計算（i表示第i個交易）：

3）平均響應(yīng)時間ART（AverageResponseTime）［13］：

4）交易延遲比例（Transaction Delay Ratio）：

在工具中還將分析記錄最大響應(yīng)時間、最小響應(yīng)時間、有效交易數(shù)量和無效交易數(shù)量及比例。后續(xù)實驗，主要針對吞吐率、平均響應(yīng)時間、延遲比例進行分析。

2.3 實驗方案

1）實驗對象

測試網(wǎng)絡(luò)由兩個機構(gòu)，各有兩個peer節(jié)點［14］組成。

2）交易讀寫方式

在測試中，需要測試寫入交易和查詢交易的性能，交易通過單鍵值對的方式寫入，測試過程中，設(shè)置單個鍵值對小于10bytes，從而盡可能測得最大寫入性能。查詢交易時，通過API提供的getState方法進行單鍵值讀取。

3）軟硬件環(huán)境

測試的主機硬件配置為 Intel（R）Core（TM）i7-6700 CPU@3.40GHz，內(nèi)存 16GB；主機系統(tǒng)為ubuntu 16.04LTS；軟件環(huán)境如表1。

表1 軟件環(huán)境配置

表2 相關(guān)配置

表2中BatchTimeout是區(qū)塊發(fā)布等待時間，MaxMessageCount是區(qū)塊大小，即每個區(qū)塊包含最大交易數(shù)量。Orderer是根據(jù)配置中的BatchTimeout以及MaxMessageCount將交易分成區(qū)塊。當(dāng)交易數(shù)量達到MaxMessageCount的時候，Orderer節(jié)點將交易打包成區(qū)塊，或者當(dāng)交易數(shù)量不足MaxMessageCount時，若時間超過BatchTimeout，則將這些交易打包成區(qū)塊。

在利用Farbric SDK Node寫入交易時，設(shè)置交易延遲等待為45s。

4）實驗過程

交易寫入測試中，區(qū)塊大?。碝axMessage-Cout）的值以及并發(fā)數(shù)設(shè)置如表3。

表3 交易寫入時區(qū)塊大小和并發(fā)數(shù)設(shè)置

交易查詢測試中，并發(fā)數(shù)設(shè)置為：10、100、500、1000、2000、…、7000…。

對于同一并發(fā)數(shù)，進行50次測試，計算平均值。

3 實驗結(jié)果分析

3.1 寫入交易測試

整理分析實驗數(shù)據(jù)，不同區(qū)塊大小時，吞吐率隨并發(fā)數(shù)的變化結(jié)果如圖3。

對于同一區(qū)塊大小，吞吐率隨著并發(fā)數(shù)的增加，先遞增然后下降。這是因為隨著并發(fā)數(shù)的增加，交易產(chǎn)生延遲。當(dāng)其中一個交易產(chǎn)生延遲，響應(yīng)時間增加，從而導(dǎo)致TPS下降。同時隨著并發(fā)數(shù)的增加，交易延遲的比例也越來越高。如圖4，對于任一區(qū)塊大小，隨著并發(fā)數(shù)從200增加到300、400，交易延遲比例增加，同時平均響應(yīng)時間相應(yīng)增加，如圖5。

圖3 交易寫入的吞吐率

圖4 交易寫入的延遲比例

圖5 交易寫入的平均響應(yīng)時間

吞吐率的峰值會隨著區(qū)塊大小的增加而增加。當(dāng)區(qū)塊大小從10提高到20時，最大TPS從75提升到102.6，提升了36.8%，當(dāng)每個區(qū)塊交易數(shù)從10提高到50的時候，TPS從75提高到了117.6，提升了56.8%。但是當(dāng)區(qū)塊大小繼續(xù)增大，峰值TPS下降，如當(dāng)區(qū)塊大小為100的時候的最大TPS小于區(qū)塊大小為50的最大TPS。

當(dāng)交易并發(fā)數(shù)小于50的時候，區(qū)塊大小較小時，吞吐率高，區(qū)塊大小設(shè)置為50的吞吐率小于區(qū)塊大小為10以及20，但高于區(qū)塊大小為100的時候的吞吐率。

當(dāng)交易并發(fā)數(shù)大于200的時候，區(qū)塊大小為100的時候，吞吐率高于其它區(qū)塊大小的吞吐率。在測試過程中，同樣在并發(fā)數(shù)據(jù)為300時，區(qū)塊大小為100的時候，交易延遲比例小于其他三個區(qū)塊大小的延遲比例。

3.2 查詢交易測試

對于交易查詢進行測試，吞吐率測試結(jié)果如圖6。

圖6 交易查詢的吞吐率

對于同一區(qū)塊大小，交易查詢的吞吐率均隨著并發(fā)數(shù)的增加先遞增，然后下降，如圖6，最大吞吐率穩(wěn)定在625，并且不同的區(qū)塊大小對交易查詢的吞吐率無顯著影響，不同區(qū)塊大小的吞吐率曲線基本重合。

圖7 交易查詢的平均響應(yīng)時間

對于交易查詢的平均響應(yīng)時間如圖7，隨著并發(fā)數(shù)的增加，平均響應(yīng)時間線性增加，同時交易的查詢平均響應(yīng)時間基本不受區(qū)塊大小的影響。

4 分析與比較

相比較Caliper和其他研究，該測試工具具有以下特點。

1）適應(yīng)Fabric 1.3版本：基于Fabric SDK Node開發(fā)，適用于通過該SDK開發(fā)的應(yīng)用測試，支持Fabric 1.3版本。

2）非延遲的負載施加方式：該工具通過改變不同的并發(fā)數(shù)，并以客戶端最大速率來施加不同負載，而Caliper通過改變交易請求速率施加負載。

3）客戶端測試：該工具是基于客戶端測試，測試通過Fabric SDK Node訪問Fabric網(wǎng)絡(luò)的負載能力，而不同于其他研究中的服務(wù)器端測試［16］。

4）可擴展性：測試工具中采集了基本數(shù)據(jù)，如每個交易的起止時間，響應(yīng)時間等數(shù)據(jù)，同時又能通過基本數(shù)據(jù)分析統(tǒng)計其它數(shù)據(jù)，如延遲交易比例、吞吐率、平均響應(yīng)時間、最大或者最小響應(yīng)時間等。同時將所有采集到的數(shù)據(jù)記錄在本地文件中，可以進行二次分析。

5 結(jié)語

本文介紹了一種基于Fabric SDK Node，適應(yīng)Fabric 1.3版本的客戶端負載測試工具。該工具通過改變并發(fā)數(shù)施加不同負載，進行負載測試，同時可以采集多種數(shù)據(jù)進行本地記錄，進行再次分析，具有較好的擴展性。同時使用該工具針對Fabric 1.3版本，測試不同區(qū)塊大小時，通過Fabric SDK Node訪問網(wǎng)絡(luò)，peer對Fabric的讀寫性能。通過測試，寫入交易時，對于并發(fā)數(shù)較低的情況設(shè)置較小區(qū)塊大小比較合適，對于較高并發(fā)數(shù)的情況建議設(shè)置較大區(qū)塊大小，但同時，區(qū)塊越大，峰值的TPS會降低；在查詢交易時，區(qū)塊大小對查詢性能基本不產(chǎn)生影響。在以后的研究中，還將繼續(xù)完善該測試工具，并從更多的角度去測試區(qū)塊鏈的性能，研究區(qū)塊鏈性能的影響因素；也將進一步對多鍵值寫入和查詢進行負載測試。