EOSIO 程序實測分析與技術建議

由 熱鏈中的人 於 5 月 7, 2018

作者：袁煜明

文章來源：火幣研究院

摘要

火幣區塊鏈應用研究院對 EOSIO 的 Dawn 3.0 版本在測試環境中通過多個場景的測試對比進行了平臺性能的研究分析。

基於測試條件下（局域網環境內的 AWS 服務器）的 EOSIO 最大能達到 1900 TPS。這與 Dawn 3.0 說明文檔中的平均 TPS （3000）、最優 TPS （6000）和理論最優 TPS （8000）仍有差距，但可穩定達到文檔所述最差情況下 1000 TPS。

隨着服務器配置的提升，系統最大 TPS 會隨之提高。同時，在條件允許的情況下，增加超級節點（Block Producer）的服務器資源，可得到更好的整體性能。因此在主網環境下，建議爲節點使用盡可能高配置的服務器。

去中心化部署會對性能有不利影響。由於目前 EOSIO 的程序代碼還不支持多線程，因此只能使用單核 CPU，暫時無法利用並行計算提高效率。在此情況下，去中心化的部署尤其是增加超級節點並不會因分攤單個服務器壓力而提高性能，反而會增加 CPU 開銷，並可能對 TPS 產生影響。

合理使用 JIT 會有一定性能提升。該方式可降低 CPU 使用率並提高一定程度的 TPS，但需注意對穩定性的影響。

報告正文

1. 引言

目前 EOS 超級節點競選活動仍在如火如荼的進行當中。據統計，截止 5 月 2 日，目前活躍的競選組織有 102 個。與此同時，block.one 在 4 月份發佈了 EOSIO 的 Dawn 3.0 版本，並計劃於 6 月份上線主網。

此前衆多社區已組建了測試網絡，並對 EOSIO 性能尤其是每秒能處理交易數量（TPS）進行了測試。但 TPS 性能受制於編譯參數、服務器硬件、操作系統、網絡等諸多條件，測試出來的結果更多的是實驗室條件下的「理論油耗」（參考 https://steemit.com/cn/@eoseoul/bmt-eosio-tps-by-eoseoul-block-one-jit）。

因此與此前的很多測試不同，火幣區塊鏈應用研究院本次的研究分析並不是圍繞 EOSIO 是否能達到 Dan Larimer 團隊所宣稱的 1M TPS 展開，而是通過分析 Dawn3.0 在不同條件下觀測到的性能指標，對未來主網架構及服務器配置等提出思路與建議。後續如果有新版本例如 Dawn4.0 等，火幣區塊鏈應用研究院會繼續跟進研究。

另外需要注意的是：測試得到的指標數據結果不是也不應被視爲是對 EOSIO 平臺或項目最終效果的證明或確認。特此聲明。

2. 主要結論

經過測試結果與分析研究，我們得到以下主要結論及技術建議：

基於我們測試條件下（局域網環境內的 AWS 服務器）的 EOSIO 最大能達到 1900 TPS，與 Dawn 3.0 說明文檔（參考 https://medium.com/eosio/eosio-dawn-3-0-now-available-49a3b99242d7）中的平均 TPS （3000）、最優 TPS （6000）和理論最優 TPS （8000）仍有差距，但可穩定達到文檔所述最差情況下 1000 TPS。
隨着服務器配置的提升，系統最大 TPS 會隨之提高。同時，在條件允許的情況下，增加超級節點（Block Producer）的服務器資源，可得到更好的整體性能。因此在主網環境下，建議爲節點使用盡可能高配置的服務器。
由於目前 EOSIO 的程序代碼還不支持多線程，因此只能使用單核 CPU，暫時無法利用並行計算提高效率。在此情況下，去中心化的部署尤其是增加超級節點並不會因分攤單個服務器壓力而提高性能，反而會增加 CPU 開銷，並可能對 TPS 產生影響。
合理使用 JIT 可降低 CPU 使用率並提高一定程度的 TPS，但需注意對穩定性的影響。

3. 測試條件說明

3.1 測試程序版本

測試程序爲 EOSIO 的 dawn-v3.0.0 版本

3.2 測試硬件環境

亞馬遜 AWS，型號按照配置高低主要有以下兩種：
AWS EC2 t2.large （下文簡稱低配服務器）: 2 核 2.3 GHz, Intel Broadwell E5-2686v4 CPU, 8GB 內存
AWS EC2 C5.4xlarge （下文簡稱高配服務器）: 16 核 3GHz, Intel Xeon Platinum 8124M CPU，32GB 內存
服務器間爲 10Gbps 局域網網絡，通訊延遲（ping）小於 1ms
操作系統爲 Ubuntu 16.04

3.3 測試方法及工具

使用 block.one 提供的 txn_test_gen 測試插件工具發送測試交易數據並觀察實際 TPS 與系統 CPU 使用率等指標情況。（參考 https://github.com/EOSIO/eos/wiki/Testnet-Single-Host-Multinode 與 https://gist.github.com/spoonincode/fca5658326837b76fd744d39b2a25b4e）

4. 具體測試場景及結果分析

4.1 場景 1

將 1 個「超級節點」（Block Producer，以下簡稱 BP）和 1 個普通節點（Full Node，以下簡稱 FN）部署在同一臺低配服務器上。

通過連接 FN 發送測試數據的結果如下：

通過連接 BP 發送測試數據的結果如下：

值得注意的是，當報單速率爲 1700 時，雖然 BP 的 CPU 已 100% 使用，但 BP 可穩定處理；同時 FN 進程所在 CPU 的使用率起伏較大，無法及時從 BP 同步到區塊，並且隨着系統運行，BP 與 FN 之間的區塊高度差距會越拉越大。

通過該場景的結果可發現：

由於目前 EOSIO 的程序還不支持多線程，因此暫時無法利用多核 CPU 的並行計算提高效率；

BP 的 CPU 使用率低於 FN，似乎與通常對“超級節點”的認識相反。這原因可能是因爲上述兩種節點所承擔的工作不同：BP 設計理念是爲了保證交易安全性和完整性（不丟失區塊），而 FN 被設計爲對外提供服務，需要進行交易簽名、序列化、驗證等等；

報單分別通過 BP 和 FN 發送時，平臺 TPS 有顯著差異，這也與上述需要處理交易的簽名、序列化等工作有關。

4.2 場景 2

提高服務器配置，繼續觀察系統性能。將 1 個 Block Producer （以下簡稱 BP）和 1 個 Full Node （以下簡稱 FN）部署在同一臺高配服務器上。

通過連接 FN 發送測試數據的結果如下：

表 4.2a：BP 和 FN 在同一臺高配服務器上的測試結果（通過 FN 發請求）

通過連接 BP 發送測試數據的結果如下：

表 4.2b：BP 和 FN 在同一臺高配服務器上的測試結果（通過 BP 發請求）

對比場景 1 可看到，隨着服務器配置的提升，系統最大 TPS 會隨之提高。

4.3 場景 3

以上場景是將 BP 和 FN 部署在同一臺服務器上，而本場景是將 BP 和 FN 分別部署在兩臺高配服務器上。

通過連接 FN 發送測試數據的結果如下：

表 4.3a：BP 和 FN 分別在兩臺高配服務器上的測試結果（通過 FN 發請求）

通過連接 BP 發送測試數據的結果如下：

表 4.3b：BP 和 FN 分別在兩臺高配服務器上的測試結果（通過 BP 發請求）

對比場景 2 可看到，本場景中的 CPU 使用率與同條件相比略微提高，應爲處理網絡通訊的開銷；分別部署並未顯著影響 TPS，這也與目前單線程方式有關：BP 和 FN 部署在同一臺服務器上並不會爭奪 CPU 資源，因此在當前代碼未支持多線程的情況下分開部署有可能並不會因分攤壓力而提高性能，反而略微增加了 CPU 開銷。

4.4 場景 4

以上場景是將 BP 和 FN 分別部署在同一配置服務器上，而場景 4 與場景 5 是將 BP 和 FN 分別部署在不同配置的服務器上。本場景是 BP 部署在低配服務器上，FN 部署在高配服務器上。

通過連接 FN 發送測試數據的結果如下：

表 4.4a：BP 在低配服務器、FN 在高配服務器上的測試結果（通過 FN 發請求）

通過連接 BP 發送測試數據的結果如下：
表 4.4b：BP 在低配服務器、FN 在高配服務器上的測試結果（通過 BP 發請求）

4.5 場景 5

本場景是 BP 部署在高配服務器上，FN 部署在低配服務器上。
通過連接 FN 發送測試數據的結果如下：
表 4.5a：BP 在高配服務器、FN 在低配服務器上的測試結果（通過 FN 發請求）

通過連接 BP 發送測試數據的結果如下：
表 4.5b：BP 在高配服務器、FN 在低配服務器上的測試結果（通過 BP 發請求）

對比場景 4 和場景 5，在條件允許的情況下，爲 BP 分配更多的資源，可得到更好的整體性能

4.6 場景 6

以上場景是兩臺服務器的情況（1 個 BP、1 個 FN）。增加 1 個 FN 後，本場景爲 1 個 BP、2 個 FN 分別部署在 3 臺高配服務器上。
通過連接 FN 發送測試數據的結果如下：
表 4.6a：1 個 BP、2 個 FN 分別在 3 臺高配服務器上的測試結果（通過 FN 發請求）

通過連接 BP 發送測試數據的結果如下：
表 4.6b：1 個 BP、2 個 FN 分別在 3 臺高配服務器上的測試結果（通過 BP 發請求）

對比場景 2 的結果可看到，在單線程情況下增加服務器會提高 CPU 開銷，並可能對 TPS 產生影響。

4.7 場景 7

以上場景是單個 BP 的情況。我們在本場景中增加節點爲 2 個 BP 和 2 個 FN 並觀察結果。
通過連接 FN 發送測試數據的結果如下：
表 4.7a：2 個 BP、2 個 FN 分別在 4 臺高配服務器上的測試結果（通過 FN 發請求）

通過連接 BP 發送測試數據的結果如下：
表 4.7b：2 個 BP、2 個 FN 分別在 4 臺高配服務器上的測試結果（通過 BP 發請求）

對比場景 6 可看到，同等情況下的 CPU 使用率會增高，同時所能達到的最大 TPS 也有較大幅度的降低，表明增加 BP 會對性能有較大影響。如果在多節點分佈在異地的主網環境中，還會疊加網絡延遲等更爲複雜的環境因素。這對節點服務器資源提出更高要求。

4.8 場景 8

另外，在 Dawn 3.0 描述文件中提到了本版本的默認解釋器從 JIT 改爲了 Binaryen WebAssembly，這會降低性能但帶來穩定性的提高並降低編譯智能合約時的延遲。我們對場景 2 的運行參數改爲 JIT 並觀察結果。

通過連接 FN 發送測試數據的結果如下：
表 4.8a：BP 和 FN 在同一臺高配服務器上並啓用 JIT 的測試結果（通過 FN 發請求）

通過連接 BP 發送測試數據的結果如下：
表 4.8b：BP 和 FN 在同一臺高配服務器上並啓用 JIT 的測試結果（通過 BP 發請求）

對比場景 2 可看到，CPU 使用率大幅度降低，但在 CPU 並未完全使用的情況下發生測試中斷，證明 JIT 確實會影響系統穩定性

關於我們：
火幣區塊鏈應用研究院（簡稱「火幣研究院」）成立於 2016 年 4 月，於 2018 年 3 月起全面拓展區塊鏈各領域的研究與探索，主要研究內容包括區塊鏈領域的技術研究、行業分析、應用創新、模式探索等。我們希望搭建涵蓋區塊鏈完整產業鏈的研究平臺，爲區塊鏈產業人士提供堅實的理論基礎與趨勢判斷，推動整個區塊鏈行業的發展。

技術火幣知識庫