原文：

https://www.hyperledger.org/learn/publications/blockchain-performance-metrics

本文：

本文只是我對原文的一些重點的一些摘錄。
出塊頻率高低並不一定是有效的tps指標，一個塊裡包含了多少有效的交易才是重點啊。

測試系統

顯示了區塊鏈效能評估的典型配置。左側的測試線束在右側顯示了用於針對被測系統（SUT）生成負載的程式和系統。圖1中的每個術語都在本節中定義。

測試線束

這個測試線束用於執行效能評估的硬體和軟體。這個測試工具通常代表許多客戶機，這些客戶機可以注入工作負載並在任意數量的節點上進行觀察。

客戶

一個客戶是可以將工作引入系統或呼叫系統行為的實體。在區塊鏈系統中，通常在多個級別上有多種型別的客戶端。

一個負載生成客戶端代表使用者向區塊鏈網路（SUT）提交交易的節點，通常遵循自動測試指令碼。客戶機和SUT之間的介面可以從簡單的表示狀態轉移（REST）介面到全面的軟體開發工具包（SDK）。根據介面的不同，客戶機可以是無狀態的，也可以是有狀態的。

一個觀察客戶是一個節點，它接收來自SUT的通知，或者可以查詢SUT有關已提交事務的狀態，通常在自動測試指令碼之後。可以有多個觀察客戶端。觀察客戶端不能提交任何新事務。

測試系統（SUT）

定義被測系統（SUT）是一個複雜的問題。在本文件中，SUT被定義為執行和維護區塊鏈所需的硬體、軟體、網路和具體配置。或不包括任何用於加速讀取外部資料庫的時間、SUT。

節點

在區塊鏈網路的上下文中，節點是一個獨立的計算實體，它與網路中的其他節點通訊，共同協作完成交易。

節點是一個虛擬實體，從某種意義上說，它可以執行在物理硬體上，也可以作為VM或容器化環境執行。在後一種情況下，節點可以與同一網路中的其他節點共享物理硬體。

關鍵指標定義

本節定義了幾個適用於區塊鏈的常用指標，並在適當的情況下提供了一個數學公式。有關區塊鏈上下文中延遲的進一步討論，請參見附錄A。附錄中所包含的任何實驗性指標都還不夠成熟。

讀取反應時間

讀取延遲=收到響應的時間–提交時間

讀吞吐量

讀吞吐量=總讀取運算元/總時間（秒）

讀吞吐量是一個度量在定義的時間段內完成多少個讀取操作的度量，用每秒讀取數（RPS）表示。這個指標可能會提供資訊，但不是區塊鏈效能的主要衡量標準。事實上，系統通常會部署在區塊鏈附近，以方便重要的閱讀和查詢。

事務延遲

事務延遲=（確認時間@網路閾值）–提交時間

事務延遲是一個網路範圍的檢視，它顯示事務的效果在整個網路中可用所花費的時間。測量包括從提交到結果在網路中廣泛可用的時間。這包括傳播時間和由於共識機制而產生的任何穩定時間。
此指標是按事務計算的，但在大多數情況下，報表應提供所有事務的各種統計資訊，如平均值、高值、低值和標準差。

事務吞吐量

事務吞吐量=提交的事務總數/總時間（以秒為單位）@@已提交節點
交易吞吐量是區塊鏈SUT在定義的時間段內提交有效交易的速率。請注意，這不是單個節點的速率，而是整個SUT的速率，即在網路的所有節點上提交的速率。此速率以網路大小的每秒事務數（TPS）表示。
請記住，應該從總事務中減去無效事務的總數，以得到提交的事務總數。關於如何計算延遲的進一步討論見附錄。

延遲計算示例

SUT立即終結

採用基於投票的共識的制度具有直接的最終性。一旦一個交易被提交，這個國家就被保證是不可撤銷的。與其餘的情況一樣，測試過程應該度量每個節點的承諾，以確保整個分散式系統的完全承諾。

具有概率終結性和已知拓撲的SUT

使用基於彩票的共識的系統具有概率最終性。在受控效能測試中，拓撲結構是已知的。這可能是大多數許可部署的情況。在這種情況下，只有當多個節點達到相同的狀態時，才會確認一個事務。

具有概率終結性和未知拓撲的SUT

這樣的系統通常被設計成在一個不受信任的環境中執行，匿名的“礦工”。只有有限的訪問點會暴露給客戶端。在這種情況下，確認應該被延遲，直到有足夠的塊被連結到塊/事務後面。