當一切正常時，您通常不會擔心區塊鏈測試。我們將在下面解釋為什么最好不要擱置性能評估，使用什么度量標準并充分利用它才是最好的。就讓我們一探究竟吧。

“每秒交易數”（ TPS）

在分布式系統中，TPS是一個非常模糊和反復無常的度量。

TPS測量來自分布式數據庫。它們通常使用標準化的交易類型或集合（例如，一些插入、更新、刪除以及常量選擇數）來執行，并針對特定的集群或單獨的機器進行配置。這樣的“綜合”指標并不能反映出所討論的數據庫或區塊鏈的實際性能，因為在這樣的系統中，交易處理時間可能會有所不同。

面向共識性的數據庫（請參閱“CAP-theorem”）在從其他節點接收到足夠數量的確認之前不會提交交易——這是很慢的。

面向可用性的數據庫時，如果交易被簡單地寫入磁盤，那么它就是成功的。他們立即提供更新的數據——這是非常快的（盡管這個交易可能在將來回滾）。如果交易只更新一個數據單元，則TPS將更高。如果交易更新許多數據單元（行、索引、文件），它們將彼此阻塞。

這就是為什么我們在Oracle、MSSQL、PostgreSQL和MongoDB、Redis、Tarantool之間看不到任何“TPS競爭”的原因——它們的內部機制和任務差別很大。

在我們看來，“測量區塊鏈TPS”是指進行全面的性能測量：

a）在可重復的條件下

b）具有接近實際的塊驗證器數量

c）使用不同類型的交易：

-研究區塊鏈的典型情況（例如，主要加密貨幣的transfer （））

-加載存儲子系統（每個交易都有相當大的變化）

-加載網絡帶寬（大交易大小）

- cpu加載（大規模密碼轉換或計算）

要討論我們所珍視的“每秒交易數”，您需要描述所有網絡條件、參數和基準測試邏輯。在區塊鏈中，將交易應用到某個內部數據庫并不意味著共識會接受它。

在PoW共識中，交易永遠不會最終確定。如果一個交易包含在一臺機器上的一個塊中，這并不意味著它將被整個網絡接受（例如，另一個分叉獲勝的情況）。

如果區塊鏈有一個額外的算法來確保終結性（如EOS、Ethereum 2.0、Polkadot parachains使用與祖父終結性一共識的方式），那么處理時間可以視為節點看到交易和下一個完成塊的時間。這樣的TPS是非常有用的，但是因為它們比預期的要低，所以很少見。

TPS涉及到很多東西。保持懷疑，詢問細節。

Blockchain-specific指標

本地TPS

處理交易的數量和最大/平均/分鐘處理時間（在本地節點上）是非常方便測量的，因為執行這些操作的函數通常用代碼表示。交易處理時間等于更新狀態數據庫所需的時間。例如，在“樂觀”區塊鏈中，已處理的交易可能已經經過驗證，但還沒有被一致接受。在這種情況下，節點將更新后的數據發送到客戶機（假設不會有任何鏈分叉。

這個度量不是很可靠：如果選擇另一個鏈分支作為主分支，那么關于交易的統計數據也必須回滾。在測試中，這一點常常被忽略。

“我們的區塊鏈昨天收到了8000個tps”。這些數字通常可以在簡短的項目報告中找到，因為它們很容易測量。只需一個運行節點和一個加載腳本就足夠了。在這種情況下，沒有網絡延遲會降低達成網絡共識的速度。

該指標反映了狀態數據庫在不受網絡影響的情況下的性能。這個數字并沒有反映真實的網絡帶寬，但是顯示了如果共識和網絡足夠快，它將努力達到的極限。任何區塊鏈交易的結果都是多個原子存儲寫。例如，一個比特幣支付交易涉及刪除幾個舊的UTXOs（刪除）和添加新的UTXOs（插入）。在以太坊中，執行一個小型智能合約代碼并更新幾個鍵-值對。

原子存儲寫是發現存儲子系統瓶頸和區分低級邏輯問題和內部邏輯問題的優秀指標。

區塊鏈節點可以用幾種編程語言實現——這更可靠。例如，以太坊節點有Rust和Go實現。在測試網絡性能時請記住這一點。

本地生產的區塊數量

這個簡單的指標顯示了某個驗證器生成的塊的數量。它依賴于共識，并且對于評估單個驗證者網絡的“有用性”至關重要。

因為驗證器在每個塊上都能賺錢，所以它們負責機器的穩定運行和安全。您可以確定哪個驗證器候選是最合格的、受保護的，并且準備好在具有真實用戶資產的公共網絡中工作。公制值可以公開檢查—只需下載區塊鏈并計算塊的數量。

最后結尾и不可逆轉的塊

終局性確保在區塊鏈中包含的所有交易都不會回滾，也不會被另一個鏈分叉替換。這是PoS網絡防止雙重消費攻擊和為用戶確認加密貨幣交易的一種方式。

當有一個塊完成包含該交易的鏈時，而不是當某個交易被節點接受時，用戶認為該交易是最后塊。要完成一個塊，驗證器必須在p2p網絡中接收這個塊并相互交換簽名。這里檢查區塊鏈的實際速度，因為交易完成的時刻對用戶來說是最重要的。

終結性算法也不同，它會相交并結合主要共識（閱讀：Casper在Ethereum，最后不可逆塊在EOS，外公在奇偶Polkadot和他們的修改，例如，MixBytes RANDPA）。

對于沒有完成所有塊的網絡，一個有用的度量是在最后完成的塊和當前最新的塊之間的延遲。這個數字顯示了驗證器落后了多少，這與正確的鏈一致。如果差距很大，那么最終性算法需要額外的分析和優化。

P2P層

點對點子系統——區塊鏈網絡的中間層——經常被忽略。這都要歸咎于塊交付和驗證器之間交易的模糊延遲。

當確認器的數量很少的時候，它們是本地化的，對等列表是硬編碼的，一切都工作得很好而且很快。但是，就像驗證器存在一樣，節點在地理上是分布的，丟失的數據是模擬的，我們正面臨嚴重的“tps”故障。

例如，當使用附加的終結性算法測試EOS共識性時，將驗證器的數量增加到80-100臺，分布在四大洲，對終結性幾乎沒有影響。與此同時，增加的包丟失嚴重影響了最終結果，這證明了需要額外的p2p層配置來更好地抵抗網絡包丟失（而不是高延遲）。不幸的是，有許多不同的設置和因素，只有基準測試允許我們了解所需的驗證器數量，并獲得相當舒適的區塊鏈速度。

p2p子系統的配置從文檔中很清楚，例如，看看［libp2p］、［Kademlia］協議或［BitTorrent］。

重要的p2p指標可以是：

· 進出流量

· 與其他對等點的成功/不成功連接的數量

· 返回先前緩存的數據塊的次數，以及為了找到所需的數據塊需要進一步轉發請求的次數（緩存命中/丟失模擬數據）

例如，在訪問數據時，較大的遺漏數意味著只有少數節點擁有請求的數據，而它們沒有時間將這些數據分發給每個節點。接收/發送的p2p通信量允許識別處理網絡配置或通道問題的節點。

區塊鏈節點的系統度量

區塊鏈節點的標準系統度量在大量的源代碼中都有描述，因此我們將簡要介紹。它們有助于發現邏輯瓶頸和錯誤。

中央處理器

CPU顯示處理器執行的計算量。如果CPU負載高——節點正在計算一些東西，積極使用邏輯或FPU（幾乎從未在區塊鏈中使用）。例如，后一種情況會發生，因為節點正在檢查電子簽名、使用強密碼處理事務或進行復雜的計算。

CPU可以被劃分成更多指向代碼瓶頸的指標。例如，系統時間—花在內核代碼上的時間，用戶時間—花在用戶進程上的時間，io—等待來自慢速外部設備（磁盤/網絡）的i/o，等等。

內存

現代區塊鏈使用鍵值數據庫（LevelDB、RocksDB），這些數據庫不斷地在其內存中存儲“熱”數據。任何加載的服務都會受到由錯誤或針對節點代碼的攻擊所導致的內存泄漏的影響。如果內存消耗正在增加或急劇增加，很可能是由于大量的狀態數據庫鍵、大型交易隊列或不同節點子系統之間的消息量增加造成的。

內存負載不足表明可能會增加塊數據限制或最大化交易復雜性。

響應網絡客戶機的完整節點依賴于文件緩存指標。當客戶機訪問狀態數據庫和交易日志的各個部分時，可能會出現磁盤中的舊塊并替換新塊。這反過來又降低了客戶機的響應速度。

網絡

主要的網絡指標是流量的大小（以字節為單位）、發送和接收網絡數據包的數量、丟包率。這些指標經常被低估，因為區塊鏈還不能以每秒1 Gbit的速度處理交易。

目前，一些區塊鏈項目允許用戶共享WiFi或提供存儲和發送文件或消息的服務。在測試這樣的網絡時，網絡接口流量的數量和質量變得非常重要，因為一個擁擠的網絡通道會影響機器上的所有其他服務。

存儲

磁盤子系統是所有服務中最慢的組件，常常會導致嚴重的性能問題。過多的日志記錄、意外的備份、不方便的讀/寫模式、大量的區塊鏈卷——所有這些都可能導致顯著的節點減速或過多的硬件需求。

使用磁盤的區塊鏈交易日志操作模式類似于使用寫前日志（WAL）的不同DBMS。從技術上講，交易日志可以被看作是狀態數據庫的WAL。

因此，這些存儲指標非常重要，因為它們可以確定現代鍵值數據庫中的瓶頸。讀取/寫入IOPS數、最大/最小/avg延遲以及許多其他有助于優化磁盤操作的指標。

結論

綜上所述，我們可以將度量分為：

· 區塊鏈節點度量（產生的塊的數量、處理的事務的數量、處理時間、完成時間等）

· p2p子系統指標（命中/丟失請求的數量、活動對等點的數量、p2p流量的數量和結構等）

· 系統節點指標（cpu、內存、存儲、網絡等）

每個組都很重要，因為一旦子系統錯誤，就會限制其他組件的操作。即使是少量驗證器的減速也會嚴重影響整個網絡。

在共識性和終結性算法中，最棘手的錯誤只出現在大型交易流或共識性參數更改時。他們的分析需要可重復的測試條件和復雜的負載場景。
責任編輯；zl