項目方說性能達到百萬TPS，如何測試它的可信度？ 應用系統性能提升的關鍵在于運維端的接入管理模型（AAA，認證 Authentication、授權 Authorization、計費 Accounting）及業務端的并發（Concurrency）/ 吞吐量 (Throughput) 模型。區塊鍊是典型的“運維友好型”系統，天然的自我治理能力極大程度上優化了接入管理模型，但現有區塊鍊系統的并發 / 吞吐量模型名額卻飽受诟病。無論是 BTC 的 7tps，還是 ETH 的 40tps 在傳統業務系統動辄萬級甚至十萬級 tps 面前都難以擡頭。 區塊鍊項目的需求： 聚焦底層基礎設施，項目自身行業或領域特征不明顯，易引入本行業業務；能夠實作微服務級部署，擴容友好，易遷移部署； 并發吞吐量 5k+，穩定支撐 10w 級 DAU，可靠性強。 根據需求有的放矢地尋覓區塊鍊項目，尋覓的過程其實遠比想象的簡單。區塊鍊項目多如牛毛，但純做技術架構不扯業務場景或者經濟模型的項目真心不多。通過對主流交易所的項目篩選，基本圈定了 EOS、QTUM、AELF 項目。EOS 官宣吞吐量約 3300~3500
項目方說性能達到百萬TPS，如何測試它的可信度？
應用系統性能提升的關鍵在于運維端的接入管理模型（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 并行架構。積極選用已被驗證的成熟技術元素确實是做新系統、新基礎設施時的難能可貴的姿态，進一步提升了對 AELF 項目的好感度。PS：該團隊技術的人也在社群，很 NICE 很好溝通。
Transaction，傳統 IT 人習慣叫“事務”，區塊鍊圈的人通常叫“交易”，可能是 BTC 白皮書翻譯傳承下來的吧。軟體測評應充分考慮軟體品質體系的要求，同理，對于一個區塊鍊底層架構而言，模拟價值傳輸壓力的交易激勵能夠作為區塊鍊底層基礎設施 tps 名額的驗證形式。
據此，先定義一個原子事務作為本次測試驗證的基本測試用例——“合約轉賬”。1 次“合約轉賬”包括 2 次讀 2 次寫操作，具體步驟如下：
- 從 A 賬戶讀取餘額（1 次讀）；
- 從 B 賬戶讀取餘額（1 次讀）；
- 從 A 賬戶減去金額（1 次寫）；
- 從 B 賬戶增加金額（1 次寫）。
因之前接觸過 BTC，深深歎服中本聰大神 UTXO 體系設定的精妙，但傳統應用系統往往還是依賴賬戶模型體系，是以選用一個經典的原子轉賬事務作為标準測試用例，并以該用例的執行效率作為吞吐量名額的依據。AELF 支援區塊鍊智能合約，上述原子事務須編寫為合約腳本部署至測試網。
進而，再定義一個基本的測試流程梗概：
該測試流程可作為一個典型的區塊鍊性能測評政策。以一次“合約轉賬”為一個基本業務執行單元，編寫運作于區塊鍊平台上的“合約腳本”程式，該程式能夠被區塊鍊系統各節點部署并執行。實施測評前需依據特定的用例或随機生成測試用例初始化測試資料，不同場景、不同輪次的測評實施須基于相同的測試資料以確定測試結果可信。測試資料作為交易申請相繼對主網發起激勵，對于 AELF 此類采用分布式并行化思想進行架構設計的項目，可采用多組資料并發激勵的形式以測試較高并發交易場景下區塊鍊系統的性能。測試過程中，可通過實時監視或特定時間片監視的方式判定測試用例的執行情況，時間片可設定為出塊周期的 N 倍（N<=6，借鑒 BTC 主網 6 區塊确認的慣例）。
繼續定義不同的測試場景：
- 場景 I：單機場景，1 業務處理節點 +1 業務資料集；
- 場景 II：叢集 - 單機場景，N 業務處理節點 +1 業務資料集；
- 場景 III：分布式叢集場景，N 業務處理節點 +N 業務資料集。
單機場景旨在驗證區塊鍊系統的獨立性能，因區塊鍊為分布式叢集系統，針對單機場景測評驗證對于最終全網性能名額結論的意義不是很大，但有助于我們更好地定義叢集測試的邊界。如單機測評的性能名額為 P，進行叢集測評時能夠以 P 為基礎通過節點 / 程序增長與性能名額增長之間的關系判定是否有必要進行更大規模的測評驗證。此外，在單機測試的過程中通過補充帶有網絡延遲的測試環境有助于對網絡環境影響因素進行基本的定量。
叢集 - 單機場景旨在針對面向區塊鍊底層平台所支撐的實際業務類型進行覆寫性測試。區塊鍊技術本身是去中心化的，但區塊鍊系統所支撐的上層業務可能有中心化特征，是以需要進行多對一場景的模拟測評。該場景的設計針對資料 I/O 存在固定瓶頸的情況下對區塊鍊系統業務處理吞吐量進行定量測評。
分布式叢集場景旨在針對處于 P2P 網絡拓撲中交易執行處理與交易資料協同均需實作區塊鍊共識的業務場景進行覆寫性測試。該場景為典型的區塊鍊系統場景，通過單機場景及叢集 - 單機場景的測評，能夠輔助我們對該場景下的測試邊界及測試差異性因子進行綜合分析，确定測試實施的方式及被測部署環境的典型性，進而得到較為可靠的測評結論。
區塊鍊系統的運作有多個層次，區塊鍊程式可被部署至多台伺服器（Server），每台伺服器可運作多個程序級執行個體（Worker），對 AELF 而言，每個執行個體内可以配置多個并行化業務單元（Actor）。是以性能名額 TPS 受伺服器、程序、業務單元的影響均需在測試中展現，最優 TPS 測評結果應表現在一個适宜的伺服器、程序、業務單元配置之下，在測試條件允許之内尋找這個最優的配置也是本次測評的目的之一。
綜上，拟實作的測試驗證目的包括但不限于單服務節點運作狀态下的并發執行能力及叢集環境下的性能延展性。
對 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:\Users\xxxxx\AppData\Local\aelf\config
配置資料集 資訊：
- 将代碼中的 aelf/config/database.json 拷貝至配置檔案目錄
- 根據本機 Redis 安裝情況修改配置
單機場景 部署：
将代碼中的 aelf/config/actor.json 拷貝至配置檔案目錄，并根據本機情況配置 IsCluster、WorkerCount、Benchmark、ConcurrencyLevel
運作 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
上圖測試環境為 8 個 Redis 執行個體建構的叢集，5 個 Twemproxy，每台伺服器連接配接不同的 Twemproxy，TPS 名額能夠随擴容而增長至理想值附近。
其他相關測試參數：使用 240000 個交易，重複 5 次。
通過上述測試驗證的執行結果基本能夠看出随着系統的擴容，吞吐量性能名額的增長是較為健康的，測試範圍之内預期最優名額約為 1.3w~1.5w tps。此外，在每一組特定的部署模式下，能夠通過系統調優獲得平均約 10%~15% 的性能提升，吞吐量性能曲線的極值點符合較為合理，符合快升緩降的泊松分布。目前小拓撲叢集下的環境搭建驗證基本能夠滿足中小型業務系統的吞吐量需求，初步可應用于傳統應用系統的優化重構——當然，隻用區塊鍊技術做分布式資料庫和通信元件難免有點大材小用，後續還需關注多級側鍊體系的測試情況，進一步融和分布式業務模型。
簡單的測試驗證後，同為搬磚碼農的筆者也有一些建議給 AELF 技術團隊：
- 當 Transaction 數量級較大，且後續引入側鍊的結構較複雜時，目前的分組政策耗時可能會有比較顯著的提升，如 10w 級事務分 1k 級處理單元組時，可能的分組時間會達到 800ms~1000ms，分組政策在後續多級側鍊體系下有待進一步優化；
- 系統目前配置的 Round-Robin-Group 路由政策在生産環境下并非最優，路由能力可通過配置調優的方式得到進一步提升；