電子發(fā)燒友App
當(dāng)一切正常時，您通常不會擔(dān)心區(qū)塊鏈測試。我們將在下面解釋為什么最好不要擱置性能評估，使用什么度量標(biāo)準(zhǔn)并充分利用它才是最好的。就讓我們一探究竟吧。
“每秒交易數(shù)”（ TPS）
在分布式系統(tǒng)中，TPS是一個非常模糊和反復(fù)無常的度量。
TPS測量來自分布式數(shù)據(jù)庫。它們通常使用標(biāo)準(zhǔn)化的交易類型或集合（例如，一些插入、更新、刪除以及常量選擇數(shù)）來執(zhí)行，并針對特定的集群或單獨的機器進行配置。這樣的“綜合”指標(biāo)并不能反映出所討論的數(shù)據(jù)庫或區(qū)塊鏈的實際性能，因為在這樣的系統(tǒng)中，交易處理時間可能會有所不同。
面向共識性的數(shù)據(jù)庫（請參閱“CAP-theorem”）在從其他節(jié)點接收到足夠數(shù)量的確認(rèn)之前不會提交交易——這是很慢的。
面向可用性的數(shù)據(jù)庫時，如果交易被簡單地寫入磁盤，那么它就是成功的。他們立即提供更新的數(shù)據(jù)——這是非?？斓模ūM管這個交易可能在將來回滾）。如果交易只更新一個數(shù)據(jù)單元，則TPS將更高。如果交易更新許多數(shù)據(jù)單元（行、索引、文件），它們將彼此阻塞。
這就是為什么我們在Oracle、MSSQL、PostgreSQL和MongoDB、Redis、Tarantool之間看不到任何“TPS競爭”的原因——它們的內(nèi)部機制和任務(wù)差別很大。
在我們看來，“測量區(qū)塊鏈TPS”是指進行全面的性能測量：
a）在可重復(fù)的條件下
b）具有接近實際的塊驗證器數(shù)量
c）使用不同類型的交易：
-研究區(qū)塊鏈的典型情況（例如，主要加密貨幣的transfer （））
-加載存儲子系統(tǒng)（每個交易都有相當(dāng)大的變化）
-加載網(wǎng)絡(luò)帶寬（大交易大小）
- cpu加載（大規(guī)模密碼轉(zhuǎn)換或計算）
要討論我們所珍視的“每秒交易數(shù)”，您需要描述所有網(wǎng)絡(luò)條件、參數(shù)和基準(zhǔn)測試邏輯。在區(qū)塊鏈中，將交易應(yīng)用到某個內(nèi)部數(shù)據(jù)庫并不意味著共識會接受它。
在PoW共識中，交易永遠不會最終確定。如果一個交易包含在一臺機器上的一個塊中，這并不意味著它將被整個網(wǎng)絡(luò)接受（例如，另一個分叉獲勝的情況）。
如果區(qū)塊鏈有一個額外的算法來確保終結(jié)性（如EOS、Ethereum 2.0、Polkadot parachains使用與祖父終結(jié)性一共識的方式），那么處理時間可以視為節(jié)點看到交易和下一個完成塊的時間。這樣的TPS是非常有用的，但是因為它們比預(yù)期的要低，所以很少見。
TPS涉及到很多東西。保持懷疑，詢問細節(jié)。
Blockchain-specific指標(biāo)
本地TPS
處理交易的數(shù)量和最大/平均/分鐘處理時間（在本地節(jié)點上）是非常方便測量的，因為執(zhí)行這些操作的函數(shù)通常用代碼表示。交易處理時間等于更新狀態(tài)數(shù)據(jù)庫所需的時間。例如，在“樂觀”區(qū)塊鏈中，已處理的交易可能已經(jīng)經(jīng)過驗證，但還沒有被一致接受。在這種情況下，節(jié)點將更新后的數(shù)據(jù)發(fā)送到客戶機（假設(shè)不會有任何鏈分叉。
這個度量不是很可靠：如果選擇另一個鏈分支作為主分支，那么關(guān)于交易的統(tǒng)計數(shù)據(jù)也必須回滾。在測試中，這一點常常被忽略。
“我們的區(qū)塊鏈昨天收到了8000個tps”。這些數(shù)字通?？梢栽诤喍痰捻椖繄蟾嬷姓业?，因為它們很容易測量。只需一個運行節(jié)點和一個加載腳本就足夠了。在這種情況下，沒有網(wǎng)絡(luò)延遲會降低達成網(wǎng)絡(luò)共識的速度。
該指標(biāo)反映了狀態(tài)數(shù)據(jù)庫在不受網(wǎng)絡(luò)影響的情況下的性能。這個數(shù)字并沒有反映真實的網(wǎng)絡(luò)帶寬，但是顯示了如果共識和網(wǎng)絡(luò)足夠快，它將努力達到的極限。任何區(qū)塊鏈交易的結(jié)果都是多個原子存儲寫。例如，一個比特幣支付交易涉及刪除幾個舊的UTXOs（刪除）和添加新的UTXOs（插入）。在以太坊中，執(zhí)行一個小型智能合約代碼并更新幾個鍵-值對。
原子存儲寫是發(fā)現(xiàn)存儲子系統(tǒng)瓶頸和區(qū)分低級邏輯問題和內(nèi)部邏輯問題的優(yōu)秀指標(biāo)。
區(qū)塊鏈節(jié)點可以用幾種編程語言實現(xiàn)——這更可靠。例如，以太坊節(jié)點有Rust和Go實現(xiàn)。在測試網(wǎng)絡(luò)性能時請記住這一點。
本地生產(chǎn)的區(qū)塊數(shù)量
這個簡單的指標(biāo)顯示了某個驗證器生成的塊的數(shù)量。它依賴于共識，并且對于評估單個驗證者網(wǎng)絡(luò)的“有用性”至關(guān)重要。
因為驗證器在每個塊上都能賺錢，所以它們負責(zé)機器的穩(wěn)定運行和安全。您可以確定哪個驗證器候選是最合格的、受保護的，并且準(zhǔn)備好在具有真實用戶資產(chǎn)的公共網(wǎng)絡(luò)中工作。公制值可以公開檢查—只需下載區(qū)塊鏈并計算塊的數(shù)量。
最后結(jié)尾и不可逆轉(zhuǎn)的塊
終局性確保在區(qū)塊鏈中包含的所有交易都不會回滾，也不會被另一個鏈分叉替換。這是PoS網(wǎng)絡(luò)防止雙重消費攻擊和為用戶確認(rèn)加密貨幣交易的一種方式。
當(dāng)有一個塊完成包含該交易的鏈時，而不是當(dāng)某個交易被節(jié)點接受時，用戶認(rèn)為該交易是最后塊。要完成一個塊，驗證器必須在p2p網(wǎng)絡(luò)中接收這個塊并相互交換簽名。這里檢查區(qū)塊鏈的實際速度，因為交易完成的時刻對用戶來說是最重要的。
終結(jié)性算法也不同，它會相交并結(jié)合主要共識（閱讀：Casper在Ethereum，最后不可逆塊在EOS，外公在奇偶Polkadot和他們的修改，例如，MixBytes RANDPA）。
對于沒有完成所有塊的網(wǎng)絡(luò)，一個有用的度量是在最后完成的塊和當(dāng)前最新的塊之間的延遲。這個數(shù)字顯示了驗證器落后了多少，這與正確的鏈一致。如果差距很大，那么最終性算法需要額外的分析和優(yōu)化。
P2P層
點對點子系統(tǒng)——區(qū)塊鏈網(wǎng)絡(luò)的中間層——經(jīng)常被忽略。這都要歸咎于塊交付和驗證器之間交易的模糊延遲。
當(dāng)確認(rèn)器的數(shù)量很少的時候，它們是本地化的，對等列表是硬編碼的，一切都工作得很好而且很快。但是，就像驗證器存在一樣，節(jié)點在地理上是分布的，丟失的數(shù)據(jù)是模擬的，我們正面臨嚴(yán)重的“tps”故障。
例如，當(dāng)使用附加的終結(jié)性算法測試EOS共識性時，將驗證器的數(shù)量增加到80-100臺，分布在四大洲，對終結(jié)性幾乎沒有影響。與此同時，增加的包丟失嚴(yán)重影響了最終結(jié)果，這證明了需要額外的p2p層配置來更好地抵抗網(wǎng)絡(luò)包丟失（而不是高延遲）。不幸的是，有許多不同的設(shè)置和因素，只有基準(zhǔn)測試允許我們了解所需的驗證器數(shù)量，并獲得相當(dāng)舒適的區(qū)塊鏈速度。
p2p子系統(tǒng)的配置從文檔中很清楚，例如，看看［libp2p］、［Kademlia］協(xié)議或［BitTorrent］。
重要的p2p指標(biāo)可以是：
· 進出流量
· 與其他對等點的成功/不成功連接的數(shù)量
· 返回先前緩存的數(shù)據(jù)塊的次數(shù)，以及為了找到所需的數(shù)據(jù)塊需要進一步轉(zhuǎn)發(fā)請求的次數(shù)（緩存命中/丟失模擬數(shù)據(jù)）
例如，在訪問數(shù)據(jù)時，較大的遺漏數(shù)意味著只有少數(shù)節(jié)點擁有請求的數(shù)據(jù)，而它們沒有時間將這些數(shù)據(jù)分發(fā)給每個節(jié)點。接收/發(fā)送的p2p通信量允許識別處理網(wǎng)絡(luò)配置或通道問題的節(jié)點。
區(qū)塊鏈節(jié)點的系統(tǒng)度量
區(qū)塊鏈節(jié)點的標(biāo)準(zhǔn)系統(tǒng)度量在大量的源代碼中都有描述，因此我們將簡要介紹。它們有助于發(fā)現(xiàn)邏輯瓶頸和錯誤。
中央處理器
CPU顯示處理器執(zhí)行的計算量。如果CPU負載高——節(jié)點正在計算一些東西，積極使用邏輯或FPU（幾乎從未在區(qū)塊鏈中使用）。例如，后一種情況會發(fā)生，因為節(jié)點正在檢查電子簽名、使用強密碼處理事務(wù)或進行復(fù)雜的計算。
CPU可以被劃分成更多指向代碼瓶頸的指標(biāo)。例如，系統(tǒng)時間—花在內(nèi)核代碼上的時間，用戶時間—花在用戶進程上的時間，io—等待來自慢速外部設(shè)備（磁盤/網(wǎng)絡(luò)）的i/o，等等。
內(nèi)存
現(xiàn)代區(qū)塊鏈?zhǔn)褂面I值數(shù)據(jù)庫（LevelDB、RocksDB），這些數(shù)據(jù)庫不斷地在其內(nèi)存中存儲“熱”數(shù)據(jù)。任何加載的服務(wù)都會受到由錯誤或針對節(jié)點代碼的攻擊所導(dǎo)致的內(nèi)存泄漏的影響。如果內(nèi)存消耗正在增加或急劇增加，很可能是由于大量的狀態(tài)數(shù)據(jù)庫鍵、大型交易隊列或不同節(jié)點子系統(tǒng)之間的消息量增加造成的。
內(nèi)存負載不足表明可能會增加塊數(shù)據(jù)限制或最大化交易復(fù)雜性。
響應(yīng)網(wǎng)絡(luò)客戶機的完整節(jié)點依賴于文件緩存指標(biāo)。當(dāng)客戶機訪問狀態(tài)數(shù)據(jù)庫和交易日志的各個部分時，可能會出現(xiàn)磁盤中的舊塊并替換新塊。這反過來又降低了客戶機的響應(yīng)速度。
網(wǎng)絡(luò)
主要的網(wǎng)絡(luò)指標(biāo)是流量的大?。ㄒ宰止?jié)為單位）、發(fā)送和接收網(wǎng)絡(luò)數(shù)據(jù)包的數(shù)量、丟包率。這些指標(biāo)經(jīng)常被低估，因為區(qū)塊鏈還不能以每秒1 Gbit的速度處理交易。
目前，一些區(qū)塊鏈項目允許用戶共享WiFi或提供存儲和發(fā)送文件或消息的服務(wù)。在測試這樣的網(wǎng)絡(luò)時，網(wǎng)絡(luò)接口流量的數(shù)量和質(zhì)量變得非常重要，因為一個擁擠的網(wǎng)絡(luò)通道會影響機器上的所有其他服務(wù)。
存儲
磁盤子系統(tǒng)是所有服務(wù)中最慢的組件，常常會導(dǎo)致嚴(yán)重的性能問題。過多的日志記錄、意外的備份、不方便的讀/寫模式、大量的區(qū)塊鏈卷——所有這些都可能導(dǎo)致顯著的節(jié)點減速或過多的硬件需求。
使用磁盤的區(qū)塊鏈交易日志操作模式類似于使用寫前日志（WAL）的不同DBMS。從技術(shù)上講，交易日志可以被看作是狀態(tài)數(shù)據(jù)庫的WAL。
因此，這些存儲指標(biāo)非常重要，因為它們可以確定現(xiàn)代鍵值數(shù)據(jù)庫中的瓶頸。讀取/寫入IOPS數(shù)、最大/最小/avg延遲以及許多其他有助于優(yōu)化磁盤操作的指標(biāo)。
結(jié)論
綜上所述，我們可以將度量分為：
· 區(qū)塊鏈節(jié)點度量（產(chǎn)生的塊的數(shù)量、處理的事務(wù)的數(shù)量、處理時間、完成時間等）
· p2p子系統(tǒng)指標(biāo)（命中/丟失請求的數(shù)量、活動對等點的數(shù)量、p2p流量的數(shù)量和結(jié)構(gòu)等）
· 系統(tǒng)節(jié)點指標(biāo)（cpu、內(nèi)存、存儲、網(wǎng)絡(luò)等）
每個組都很重要，因為一旦子系統(tǒng)錯誤，就會限制其他組件的操作。即使是少量驗證器的減速也會嚴(yán)重影響整個網(wǎng)絡(luò)。
在共識性和終結(jié)性算法中，最棘手的錯誤只出現(xiàn)在大型交易流或共識性參數(shù)更改時。他們的分析需要可重復(fù)的測試條件和復(fù)雜的負載場景。
責(zé)任編輯：ct
工商網(wǎng)監(jiān)
評論