區塊鏈性能測試與優化-上篇_區塊鏈

本篇文章目的是通過具體示例，介紹完整的性能項目過程，具體內容介紹區塊鏈性能測試中使用的：1.?基本概念

2.?常用工具

3.?性能調優的常見情況

這?3?塊內容涵蓋的內容非常多，每一個內容都有很多書籍和文章介紹，詳細的內容不會出現在本文中。

區塊鏈的性能測試，方法論上與傳統的性能測試沒有不同。性能測試有很多混亂的概念，這里我列出本文描述概念做一些定義。性能測試是對系統或者服務的性能指標建立監控策略，在特定場景下執行測試，分析判斷性能瓶頸并調優，最終得出性能結果來評估系統或者服務的性能指標是否滿足既定值。這里結合?cosmos-sdk?的?simapp?區塊鏈來解釋。1.需要明確指標，一般指兩類指標:技術指標、業務指標。技術指標一般是?TPS，響應時間，資源利用率，對應到區塊鏈一般是指每秒可以處理多少筆交易？這些交易的響應時間或者統計結果是多少？在這種情況下系統使用的資源處于什么狀態？期望滿足的業務指標，應該來源于生產環境統計，以?cosmos-sdk?的生產應用?cosmos-hub?為例，其現階段出塊時間大約?6?秒，每個區塊中的交易數大多數小于?10?。期望的業務指標設定為?TPS?為?100?是較為合理的。。

2.測試模型:是真實場景的抽象，描述業務模型是什么樣的。以?cosmos-hub?為例大致就是，分布在全球的區塊鏈節點，在驗證者節點約?500?個，活躍驗證者節點約為?200?的情況下處理交易。測試時可以按比例抽象實際情況。

聲音 | 中裝建設：公司遠期將要成為裝飾行業區塊鏈平臺，不存在概念炒作:金色財經報道，深圳市中裝建設集團股份有限公司發布關于深圳證券交易所問詢函回復的公告。公告稱，目前，公司的區塊鏈技術平臺立足于服務公司現有業務體系內的供應鏈交易，遠期將要成為裝飾行業這個垂直細分領域的區塊鏈平臺。目前，在裝飾行業內尚無明確的直接競爭對手。隨著公司區塊鏈技術平臺的開發進展，公司預期對于算力、對于數據存儲都會有越來越高的要求。IDC和云計算將為公司區塊鏈業務的平臺化發展提供基礎能力，是重要的基礎設施。公司長期看好IDC和云計算市場，通過入股安訊集團來進入IDC和云計算市場，一方面是公司本身區塊鏈業務發展的基礎需要，另一方面也是看好IDC和云計算市場的發展。公司在切切實實地投入、開展相關業務，不存在利用云計算、區塊鏈等概念炒作股價情形，也不存在配合股東減持情形。[2020/2/19]

3.測試方案:包括測試環境，測試數據，測試模型，性能指標等。對比區塊鏈系統的測試，就是確定測試架構，準備好如?1000?個用戶，每個用戶余額?1000?stake?這樣的內容。

4.需要有監控:監控的對象有壓力機、區塊鏈節點、其他如負載均衡服務器等。云原生時代的監控一般是?KubernetesPrometheusGrafana。

動態 | NEM新區塊鏈Catapult測試網發布延遲:NEM已推遲原定于11月27日的新區塊鏈Catapult測試網發布計劃。NEM官方表示，由于配置問題以及密鑰的正確生成，測試時遇到了幾個障礙，但目前已經部署了一些節點。隨著fushicho2的改變，技術棧需要復雜的調試，這也影響了發布進展。此外，遷移到測試網要求錢包、瀏覽器、REST、sdk等所有配套設施的兼容，關于這方面的更多細節將在后續的遷移更新中進行概述。[2019/11/29]

5.需要測試條件：硬件環境，測試執行策略等。例如:4?C?8?G,前?60?秒，每秒增加?10?個線程。

6.需要有場景：指性能場景，正式化的描述是:在既定的環境、既定的數據、既定的執行策略、既定的監控之下，執行性能腳本，同時觀察系統各層級的性能狀態參數變化，并實時判斷分析場景是否符合預期。性能場景，有時被稱為測試用例其實是不對的。

7.要有結果報告：報告內容當然就是實際的指標數據。

1.基準性能場景：做單交易/接口的容量，為混合容量做準備。

2.容量性能場景：混合容量測試是因為線上真實場景就是由不同的業務組成的，所以由這些業務按照不同并發比例發起梯度壓測就是混合容量測試場景。

聲音 | Jason Goldwater：區塊鏈有三大潛力解決醫療問題:據CNN消息，華盛頓全美質量研討會高級主任Jason Goldwater撰文稱，區塊鏈有潛力在以下三個方面解決醫療問題：

首先是解決數據訪問的問題。區塊鏈利用了的分布式分類帳本技術。從某種程度上來說，侵入一個中心化的區域來查找大量數據漏洞進而攻擊數據會更容易得多，然而想要從分布式廣域網絡中獲取大量數據漏洞卻并不輕松。

其二，區塊鏈在互操作性方面具有潛能。人們對區塊鏈的關注度大部分源于此，因為在互操作性方面具有深遠的潛力，它允許數據以任何語法和任何結構在不同位置之間流動。

區塊鏈的第三大潛力，是它可以幫助推進患者參與和患者授權的理念。[2018/11/30]

3.穩定性性能場景：核心就是時長，在長時間的運行之下，觀察系統的性能表現。這個時長的設置，應該來源于運維周期。

4.異常性能場景：在強壓力之下，模擬異常。

性能測試的指標有很多，比如：1.?RT,ResponseTime

2.?HPS,HitsPerSecond

3.?TPS,TransactionsPerSecond,這里的?Transactions?在傳統的應用中一般稱為”事務“，在區塊鏈領域指”交易“

聲音 | 火幣周報：區塊鏈資產市值普遍上漲 前100項目中僅12個市值下跌:據火幣第20期區塊鏈行業周報，本周區塊鏈資產市值普遍上漲，TOP100項目中88個項目市值有不同程度上漲，12個項目下跌。

本周比特幣的區塊大小、區塊平均交易數均下降、以太坊的區塊大小和平均交易數也均上升。比特幣平均未確認交易數相比上周同期減少25.9%，以太坊平均未確認交易數相比上周同期增加26.77%。比特幣礦工費小幅上升，以太坊礦工費大幅下降。

ZSC代碼活躍程度最高，Mainframe成為telegram社區關注度最高的項目。本周新數字資產分布以新加坡為主，金融類應用為主要應用領域。[2018/7/24]

4.?QPS,QueriesPerSecond

5.?PV,PageView

6.?Throughput

7.?IOPS,Input/OutputOperationsPerSecond

比較重要的指標有資源使用率、吞吐量、響應時間，服務提供方比較關心前兩者，用戶更更新后者。關于這些指標的一般情況引用?PerformanceTestingMethodology(http://hosteddocs.ittoolbox.com/questnolg?22106?java.pdf)中的經典圖來說明，實際情況可能不同。圖中定義了?3?線?3?區域?3?狀態，這個圖值得多看看，能夠大致理解指標簡的關系。

金色財經獨家分析 SBI全球布局區塊鏈產業:金色財經獨家分析，SBI出資上千萬美元收購臺灣區塊鏈相關企業OwlTing20%股份，日本金融巨頭SBI集團正在區塊鏈領域正在大步向前，旗下子公司區塊鏈相關項目不斷。之前位于俄羅斯的商業銀行SBI Bank LLC是日本金融巨頭SBI集團的子公司，該銀行現已加入位于紐約的銀行業區塊鏈聯盟R3。日本SBI Sumishin網絡銀行稱將會開發概念證明（POC，proog-of-concept），旨在和野村綜合研究所（NRI，Nomura Research Institute）探索區塊鏈銀行的應用。日本投資集團SBI金融科技子公司SBI Cosmoney年初宣布與韓國比特幣交易所Coinplug聯合創辦匯款合資公司。可以看到這家日本財團，用旗下子公司在全球部署區塊鏈項目，涉及到的區塊鏈產業從底層技術到交易所，另外除了和交易所合作外，有報道稱日本的SBI集團將于2018年4月26日，計劃今年夏天推出自己的加密貨幣交易所。可見SBI對于區塊鏈產業的決心，對比國內大型企業同樣在搶占區塊鏈產業的產業鏈上下游，各家大企業都不愿錯失區塊鏈這一“大蛋糕”。[2018/5/10]

1.?3?線:Utilization，Throughput，ResponseTime

2.?3?區域:LightLoad,HeavyLoad,BuckleZone

3.?3?狀態:ResourceSaturated,ThroughputFalling,?EndUsersEffected

1.一般需要在什么時候做性能測試。

a.項目上線前，估計系統承載能力

b.?項目重構后，評估效果

2.如果一個項目得到性能報告就終止，這樣就只是性能驗證。做完全面的性能測試，同時將系統調優到最優狀態，才算是一個完整的性能項目了。性能調優耗時長，還可能需要開發參與，代價高。

區塊鏈性能測試

區塊鏈的性能測試的指標最重要的是?TPS?與延遲，a16z的文章Whyblockchainperformanceishardtomeasure?對此做了很有洞察的討論，說明了為什么這兩個指標很難測量和比較。其主要內容有以下方面：

延遲的這段時間的起點和終點如何定義？1.起點是用戶點擊提交還是交易到達內存池？

2.終點是交易被第?1?個區塊確認？還是被第?6?個區塊確認？又或者是最終用戶收到接口響應的時間？

3.有些區塊鏈系統對交易會等待一定延遲和到達一定數量才開始處理。這樣比較幸運的就是最后加入的交易，其處理延遲最短。

4.對于上訴問題的一種折中方案是，即準確評估整個系統需要考慮延時的分布，而不是將其延遲看做單一數字。

5.有些區塊鏈系統的交易處理是有優先級的，fee?高的交易很快確認，fee?低的相對慢些。fee?的不同對交易的延時和?TPS?的統計是有影響的。

區塊鏈中的吞吐量，即?TPS(TransactionPerSecond)來衡量，這里的?transaction?顯示不是平等的，最簡單的例子就是以太坊中的交易，它可以是轉賬也可以是調用合約。因此，得出?TPS?需要指定?T?指代的是什么。

另外一個實際的問題是，用戶其實不關心一個區塊鏈的?TPS?是多少，用戶只關心如何少用?fee?并盡快完成交易。從這個角度來講，TPS?只對系統服務提供商有意義。

壓力工具

壓力工具一般用Jmeter或者特定應用專用測試工具如下:

1.?hyperbench/hyperbench

2.?hyperledger/caliper:Ablockchainbenchmarkframeworktomeasureperformanceofmultipleblockchainsolutions?

3.?https://github.com/xuperchain/xbench

4.?…

使用?Jmeter?應該是更貼近使用場景，更通用。一般與區塊鏈節點進行交互的方式有

1.?gRPC?協議

2.?HTTP?協議(REST?接口)

Jmeter?支持的?Sampler?支持有?HTTP，對?gRPC?協議的支持需要借助插件jmeter-grpc-request

監控工具一般用Prometheus這工具可以監控的內容比較多，其生態如圖(https://prometheus.io/assets/architecture.png)。在測試區塊鏈應用的實踐中，一般是先使用?docker-compose?部署多個區塊鏈節點模擬正式進行測試的環境，因為正式的測試環境一般硬件配置較高，如果不是自建機房，使用云服務廠商的機器，費用昂貴，這樣做可以節約成本。

docker-compose?中可以限制容器使用的資源，如內存和?CPU?算力，甚至綁定?CPU?核心，對這些資源的監控可以使用cadvisor。

為了驗證?CPU?限制是否準確，可以用stress-ng壓滿核心，看統計結果是否與限制值一致。

一般遇到性能瓶頸的常見元原因會是網絡、CPU、磁盤?IO。引發磁盤?IO?的瓶頸的操作有寫日志頻頻繁，打印不必要的日志，通過網絡訪問磁盤等。這些資源都會通過系統調用來完成，跟蹤系統調用，可以使用?strace?來查看執行了哪些系統調用，以及在這些調用上花費的時間等信息

還可能遇到的問題是系統不穩定，可以表現為?CPU?使用率/TPS不穩定。

如果在?LightLoad?區域選擇一定的并發壓力，TPS?波動較大的話，可能就是系統設計得不好，需要找到原因和優化了。

如果是?CPU?使用率不穩定，從?CPU?指令執行層面來看為?CPU?處于?idle?狀態的時長參差不齊。這種情況下的原因并不在于有?CPU?有?idle，而是在于處于?idle?的時間段有長有短。需要借助?Linux?系統工具、程序對應的?profilling?工具來觀測，找到原因。

要解決性能問題，首先需要找到原因，尋找原因的分析工具可以參考下圖(https://www.brendangregg.com/Perf/linux_perf_tools_full.png)。這是?Linux?性能分析最重要的參考資料了，顯示了在不同子系統出現性能問題后，應該用什么樣的工具來觀測和分析。

磁盤?IO?一般會導致系統瓶頸，磁盤?IO?棧比較長，分析起來難度不小。熟悉?IO?棧，有助于我們發現問題(https://www.thomas-krenn.com/en/wikiEN/images/c/c?2/Linux-storage-stack-diagram_v?6.2.pdf)

找到原因后，如果能夠通過調整操作系統參數或者應用系統參數優化性能是比較快捷的，如果需要修改代碼，則會涉及系統架構優化，會有涉及和編碼工作，調優周期會很長。

下一篇文章將分享使用?cosmos-sdk?中的?SimApp?來進行性能測試以及在性能調優方面的方法。

Tags：區塊鏈TPSCPUMET區塊鏈域名誰在管理tps幣圈門羅幣是用cpu挖還是顯卡挖LocoMeta

OKB