項目方說性能達到百萬TPS，如何測試它的可信度？

近期區塊鏈的技術概念在傳統 IT 圈逐漸升溫，成為許多遺產系統升級重構方案的備選技術路線。筆者本人多年從事應用系統研發，目前所維護的系統性能漸露瓶頸，分片擴容難度較大且面臨分散式改進的潛在需求，因而亟需區塊鏈架構技術儲備。

應用系統性能提升的關鍵在於運維端的接入管理模型（AAA，認證 Authentication、授權 Authorization、計費 Accounting）及業務端的並發（Concurrency）/ 吞吐量 (Throughput) 模型。區塊鏈是典型的「運維友好型」系統，天然的自我治理能力極大程度上優化了接入管理模型，但現有區塊鏈系統的並發 / 吞吐量模型指標卻飽受詬病。無論是 BTC 的 7tps，還是 ETH 的 40tps 在傳統業務系統動輒萬級甚至十萬級 tps 面前都難以抬頭。

本著不重複造輪子的宗旨，首先梳理了一下對區塊鏈項目的需求：

聚焦底層基礎設施，項目自身行業或領域特徵不明顯，易引入本行業業務；

能夠實現微服務級部署，擴容友好，易遷移部署；

並發吞吐量 5k+，穩定支撐 10w 級 DAU，可靠性強。

根據需求有的放矢地尋覓區塊鏈項目，尋覓的過程其實遠比想像的簡單。區塊鏈項目多如牛毛，但純做技術框架不扯業務場景或者經濟模型的項目真心不多。通過對主流交易所的項目篩選（畢竟不能找一個不穩定的團隊做的東西），基本圈定了 EOS、QTUM、AELF 項目。EOS 官宣吞吐量約 3300~3500tps，QTUM 官宣吞吐量為 BTC 的十倍（權且估算 100tps），AELF 項目 7 月伊始發布測試網，官方暫未發布吞吐量信息。選定 AELF 作為調研對象的原因一方面是開發指南新近發布，與最近代碼版本的可操作性強，且 AELF 採用的 Akka 並發框架應用範圍較廣，先前有所接觸。

0x01 測試設計

現有的區塊鏈系統業務處理能力普遍面向價值傳遞進行建設，因此對於區塊鏈系統性能的評測思路應面向交易過程展開。AELF 項目在區塊鏈架構方面主打的特徵是「主鏈 + 多級側鏈」，鏈間有專門的跨鏈演算法實現相對隔離的業務單元間資源的協同，鏈內節點均運行於集群，節點內部通過並行化方案提升吞吐量指標。根據官方在社區披露的信息，測試網初期（即目前）提供主鏈並行計算模塊的測試驗證，確認主鏈性能後再灰度升級至多級側鏈版本，從軟體質量體系的角度而言是合理的。通過參與社區內的技術直播互動，也與項目技術團隊充分探討了 AELF 選用的幾個技術方案，尤其是 Akka 並行框架。積極選用已被驗證的成熟技術元素確實是做新系統、新基礎設施時的難能可貴的姿態，進一步提升了對 AELF 項目的好感度。PS：該團隊技術的人也在社區，很 NICE 很好溝通。

Transaction，傳統 IT 人習慣叫「事務」，區塊鏈圈的人通常叫「交易」，可能是 BTC 白皮書翻譯傳承下來的吧。軟體測評應充分考慮軟體質量體系的要求，同理，對於一個區塊鏈底層架構而言，模擬價值傳輸壓力的交易激勵能夠作為區塊鏈底層基礎設施 tps 指標的驗證形式。

據此，先定義一個原子事務作為本次測試驗證的基本測試用例——「合約轉賬」。1 次「合約轉賬」包括 2 次讀 2 次寫操作，具體步驟如下：

從 A 賬戶讀取餘額（1 次讀）；

從 B 賬戶讀取餘額（1 次讀）；

從 A 賬戶減去金額（1 次寫）；

從 B 賬戶增加金額（1 次寫）。

因之前接觸過 BTC，深深嘆服中本聰大神 UTXO 體系設置的精妙，但傳統應用系統往往還是依賴賬戶模型體系，因此選用一個經典的原子轉賬事務作為標準測試用例，並以該用例的執行效率作為吞吐量指標的依據。AELF 支持區塊鏈智能合約，上述原子事務須編寫為合約腳本部署至測試網。

進而，再定義一個基本的測試流程梗概：

該測試流程可作為一個典型的區塊鏈性能測評策略。以一次「合約轉賬」為一個基本業務執行單元，編寫運行於區塊鏈平台上的「合約腳本」程序，該程序能夠被區塊鏈系統各節點部署並執行。實施測評前需依據特定的用例或隨機生成測試用例初始化測試數據，不同場景、不同輪次的測評實施須基於相同的測試數據以確保測試結果可信。測試數據作為交易申請相繼對主網發起激勵，對於 AELF 此類採用分散式並行化思想進行架構設計的項目，可採用多組數據並發激勵的形式以測試較高並發交易場景下區塊鏈系統的性能。測試過程中，可通過實時監視或特定時間片監視的方式判定測試用例的執行情況，時間片可設置為出塊周期的 N 倍（N

繼續定義不同的測試場景：

場景 I：單機場景，1 業務處理節點 +1 業務數據集；

場景 II：集群 - 單機場景，N 業務處理節點 +1 業務數據集；

場景 III：分散式集群場景，N 業務處理節點 +N 業務數據集。

單機場景旨在驗證區塊鏈系統的獨立性能，因區塊鏈為分散式集群系統，針對單機場景測評驗證對於最終全網性能指標結論的意義不是很大，但有助於我們更好地定義集群測試的邊界。如單機測評的性能指標為 P，進行集群測評時能夠以 P 為基礎通過節點 / 進程增長與性能指標增長之間的關係判定是否有必要進行更大規模的測評驗證。此外，在單機測試的過程中通過補充帶有網路延遲的測試環境有助於對網路環境影響因素進行基本的定量。

集群 - 單機場景旨在針對面向區塊鏈底層平台所支撐的實際業務類型進行覆蓋性測試。區塊鏈技術本身是去中心化的，但區塊鏈系統所支撐的上層業務可能有中心化特徵，因此需要進行多對一場景的模擬測評。該場景的設計針對數據 I/O 存在固定瓶頸的情況下對區塊鏈系統業務處理吞吐量進行定量測評。

分散式集群場景旨在針對處於 P2P 網路拓撲中交易執行處理與交易數據協同均需實現區塊鏈共識的業務場景進行覆蓋性測試。該場景為典型的區塊鏈系統場景，通過單機場景及集群 - 單機場景的測評，能夠輔助我們對該場景下的測試邊界及測試差異性因子進行綜合分析，確定測試實施的方式及被測部署環境的典型性，從而得到較為可靠的測評結論。

區塊鏈系統的運行有多個層次，區塊鏈程序可被部署至多台伺服器（Server），每台伺服器可運行多個進程級實例（Worker），對 AELF 而言，每個實例內可以配置多個並行化業務單元（Actor）。因此性能指標 TPS 受伺服器、進程、業務單元的影響均需在測試中體現，最優 TPS 測評結果應表現在一個適宜的伺服器、進程、業務單元配置之下，在測試條件允許之內尋找這個最優的配置也是本次測評的目的之一。

綜上，擬實現的測試驗證目的包括但不限於單服務節點運行狀態下的並發執行能力及集群環境下的性能延展性。

0x02 測試搭建及部署

測試所選用的環境為標準雲平台虛擬機（包括 AWS 及阿里雲），根據官方在社區內推薦的配置，採用了 8vCPU+16G 內存的組合，網路帶寬 10G，Redis 版本 4.0.10，Twemproxy 版本 0.4.1，基本與標準集群生產環境類似，後續隨測試網內容的增多配置可能有變化，在社區隨時可以得到項目技術團隊的解答。

8 月 8 日補充：AELF 官方 Github 已給出權威版測試搭建步驟，下文為筆者的搭建步驟。

對 AELF 測試網進行開發接入的核心是釐清 Benchmark 環境，通過與技術團隊的諮詢交流，下述為基本的搭建與部署執行步驟。

克隆及編譯代碼：

git clone https://github.com/AElfProject/AElf.git aelf

cd aelf

dotnet publish –configuration Release -o /temp/aelf

確認配置文件目錄：

Mac/Linux: ~/.local/share/aelf/config

Windows: C:UsersxxxxxAppDataLocalaelfconfig

配置數據集信息：

將代碼中的 aelf/config/database.json 拷貝至配置文件目錄

根據本機 Redis 安裝情況修改配置：

單機場景部署：

將代碼中的 aelf/config/actor.json 拷貝至配置文件目錄，並根據本機情況配置 IsCluster、WorkerCount、Benchmark、ConcurrencyLevel：

運行 Benchmark：

運行 ConcurrencyManager：

dotnet AElf.Concurrency.Manager.dll --actor.host 192.168.100.1 --actor.port 4053

// --actor.host Manager 的 IP 地址 --actor.port Manager 的監聽埠

將代碼中的 aelf/config/actor.json 拷貝至配置文件目錄，並根據本集群情況配置 IsCluster、HostName、WorkerCount、Benchmark、ConcurrencyLevel、Seeds：

運行 ConcurrencyWorker：

如 Worker 收到 Manager 的歡迎信息則說明該 Worker 加入集群，後續節點擴容可依託此環境開展

運行 Benchmark：

0x03 測試執行與數據分析

該部分不再贅述具體的執行過程，直接針對三種場景給出測試驗證的數據乾貨。特彆強調，本次測試的數據結果為筆者自行測試，環境和過程可能因人為操作誤差不是很嚴謹，具體性能指標以官方發布為準，好事者勿擾！！！

場景 I 單機場景測試數據

通過上圖可以看出，當資料庫與業務單元分離部署時，網路延遲會導致 TPS 指標下降，同等網路延遲下 TPS 指標跟隨變化趨勢基本相同。

場景 II 集群 - 單機場景測試數據

通過上兩圖可以看出當數據集服務為單例部署時，2 進程 16 業務單元的部署模式較為理想。針對 2 進程 16 業務單元的部署模式又做了伺服器擴容的補充分析，分析表明在數據集服務為單例時，伺服器增長到 5 時性能達到瓶頸，TPS 指標開始下滑。

場景 III 分散式集群場景測試數據

上圖測試環境為 8 個 Redis 實例構建的集群，5 個 Twemproxy，每台伺服器連接不同的 Twemproxy，TPS 指標能夠隨擴容而增長至理想值附近。

其他相關測試參數：使用 240000 個交易，重複 5 次。

0x04 測試總結

通過上述測試驗證的執行結果基本能夠看出隨著系統的擴容，吞吐量性能指標的增長是較為健康的，測試範圍之內預期最優指標約為 1.3w~1.5w tps。此外，在每一組特定的部署模式下，能夠通過系統調優獲得平均約 10%~15% 的性能提升，吞吐量性能曲線的極值點符合較為合理，符合快升緩降的泊松分布。目前小拓撲集群下的環境搭建驗證基本能夠滿足中小型業務系統的吞吐量需求，初步可應用於傳統應用系統的優化重構——當然，只用區塊鏈技術做分散式資料庫和通信組件難免有點大材小用，後續還需關注多級側鏈體系的測試情況，進一步融和分散式業務模型。

簡單的測試驗證後，同為搬磚碼農的筆者也有一些建議給 AELF 技術團隊：

當 Transaction 數量級較大，且後續引入側鏈的結構較複雜時，目前的分組策略耗時可能會有比較顯著的提升，如 10w 級事務分 1k 級處理單元組時，可能的分組時間會達到 800ms~1000ms，分組策略在後續多級側鏈體系下有待進一步優化；

系統目前配置的 Round-Robin-Group 路由策略在生產環境下並非最優，路由能力可通過配置調優的方式得到進一步提升；

並行化事務處理過程中建議增加健康狀態監控機制，如 MailBox，以方便運維、開發團隊了解執行過程及定位問題，否則複雜關聯事務的死鎖可能會導致無法預見的系統失效。

刨除掉上述三點，該測試網目前的表現可圈可點，後續進展值得期待。以上即為對區塊鏈性能評測的方案分享。

今日薦文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！