基于區(qū)塊鏈技術的性能測試-創(chuàng)新互聯(lián)

?

成都創(chuàng)新互聯(lián)公司主要從事成都網(wǎng)站制作、做網(wǎng)站、網(wǎng)頁設計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務。立足成都服務香坊,10年網(wǎng)站建設經(jīng)驗,價格優(yōu)惠、服務專業(yè),歡迎來電咨詢建站服務:18980820575

作者：大開科技-曹向志

摘要：本次測試是受甲方公司委托，對運用區(qū)塊鏈技術的一個應用后臺系統(tǒng)進行負載測試，主要是評估系統(tǒng)在系統(tǒng)資源正常利用率下TPS是否能夠達到20000，并發(fā)用戶超過2000，響應時間不超過0.2秒。測試環(huán)境搭建全部基于云上，可以根據(jù)需要擴展應用服務器和壓力機。建立在區(qū)塊鏈技術上的應用系統(tǒng)特點是部署在Docker里，且只能通過后臺服務接口調(diào)用，部署在Tomcat之上，Berkeley DB內(nèi)存數(shù)據(jù)庫的key-value形式，是一個之前未曾測試過的一種部署。之前聽同行說過，云上服務器不好監(jiān)控，這次又是在Docker里面，是否可以監(jiān)控呢？等著我們的是否是一次挑戰(zhàn)呢？

前言：

當前，各行各業(yè)都在研究區(qū)塊鏈技術的運用，區(qū)塊鏈技術依據(jù)其自身所具備特性可部分或全部運用到某些業(yè)務領域，推動該業(yè)務領域的創(chuàng)新，例如：銀行、保險、游戲、電商等以及有實力的軟件服務集成商都投入團隊研究區(qū)塊鏈技術。其中虛擬貨幣可能是最適合區(qū)塊鏈技術運用的方向之一。我們有幸負責該領域一個軟件系統(tǒng)的性能測試，接觸到該業(yè)務領域。實屬幸運！

系統(tǒng)背景：

區(qū)塊鏈解決的是不可信網(wǎng)絡下的分布式共識計算方案。區(qū)塊鏈的效率以及規(guī)模，取決于核心共識算法。包括合法性、完整性、可終止性三個重要屬性。從最早的拜占庭將軍問題，引出一種容錯理論。隨后1985年 Fischer和Lynch發(fā)表了FLP不可能性定論和1998年Eric Brewer的CAP的三角理論法，給異步網(wǎng)絡下共識模型提供了很好的理論基礎。

在共識算法理論基礎下，有很多實現(xiàn)的計算機算法，例如Paxos、Raft、PBFT等。PBFT提出了實際的解決方案，系統(tǒng)通過訪問控制來限制失效客戶端可能造成的破壞，審核客戶端并阻止客戶端發(fā)起無權執(zhí)行的操作。同時，服務可以提供操作來改變一個客戶端的訪問權限。因為算法保證了權限撤銷操作可以被所有客戶端觀察到，這種方法可以提供強大的機制從失效的客戶端×××中恢復。

BTC比特幣采用挖礦記賬方式，即工作量證明（PoW）來解決BFT的問題。由礦工用計算機算力來解密碼學題目的方式爭奪記賬權利，并且給予勝利者一定比特幣的獎勵。工作量證明機制完全依靠經(jīng)濟激勵的方式來大量增加記賬參與者，從而稀釋作惡節(jié)點的比例，或者說大幅增加作惡的成本，做假賬者需要控制或者賄賂更多的節(jié)點?，F(xiàn)在體量大的兩條交易區(qū)塊鏈，比特幣和以太坊ETH都是用PoW挖礦的方式。

共識的性能決定了給鏈的節(jié)點間視圖數(shù)據(jù)信息一致性效率。而同步的視圖的數(shù)據(jù)，需要提供更大的存儲空間，才能為整個鏈提高區(qū)塊的批量效率。

系統(tǒng)性能測試需求：

該系統(tǒng)主要運用了區(qū)塊的形成機制，在多個節(jié)點上達成共識。通過基本賬戶轉賬交易、智能合約轉賬、隨機合約調(diào)用轉賬三種機制，在多個節(jié)點上形成共識。

該系統(tǒng)的性能指標要求：

1、 并發(fā)用戶2000

2、 TPS 2萬/秒

3、 平均響應時間0.2s

4、 10個節(jié)點資源監(jiān)控正常

5、 事務成功率達到100%

測試類型：單交易基準測試、單交易負載測試、混合業(yè)務負載測試，如果有時間，進行穩(wěn)定性測試

客戶提供的測試環(huán)境：

應用服務器軟硬件環(huán)境：阿里云 Intel(R) Xeon(R) Gold 6148 CPU 2.4GHz,16CPU、16G；軟件：操作系統(tǒng)CentOS 7.0，內(nèi)存數(shù)據(jù)庫

壓力機軟硬件環(huán)境：阿里云Inter(R) Xeon(R)Gold 614、8 CPU； CPU：Inter(R) Pentium(R) CPU G2030，2.40GHZ，8CPU內(nèi)存16G；操作系統(tǒng)：Windows server 2012

測試環(huán)境拓撲圖如下：

性能測試需求分析：

該系統(tǒng)主要對并發(fā)用戶數(shù)、響應時間、TPS、事務正確率有比較高的要求，各應用節(jié)點資源要求使用率不高于80%，對于Linux（CentOS）平臺來說，應該控制在65%利用率左右。由于該應用特點是采用節(jié)點擴展方式，所以測試的重點是通過執(zhí)行測試，找到服務器的處理能力，為后續(xù)的上線做一個服務器選擇的參考。

測試設計：

系統(tǒng)要求測試類型，單交易基準測試、單交易負載測試、混合交易負載測試。主要是確定典型交易，通過溝通，確定典型交易共有6個，基本賬戶轉賬、智能合約轉賬、隨機合約調(diào)用、交易查驗、區(qū)塊查驗和賬戶查驗。每個交易所占比例基本相同。被測試系統(tǒng)使用Tomcat部署，整個應用部署在docker里，每臺服務器也可以部署多個Docker，在測試里，沒有贊成這樣部署。

對于應用服務器的監(jiān)控，考慮可以通過Loadrunner結合vmstat、top等命令行工作監(jiān)控，對于JVM考慮是否可以通過jvisulevm監(jiān)控。實際上無法監(jiān)控。JDK版本為1.7。還是原來的內(nèi)存分配和回收策略。還沒有升級到1.8，采用元空間的方式。對于JDK，最后方案選擇使用jstat在Docker里進行監(jiān)控。

對于使用多少臺應用服務器和壓力機能夠達到要求的性能指標，無法評估，只能通過在測試幾個場景后，才能評估獲得。

壓力機盡量采用低版本的Windows server版本，因為是云上服務器，只提供服務器版本。對于高版本的Windows sever有可能在測試過程中遇到未曾遇到的新問題。

風險考慮：

由于性能測試團隊第一次在基于云上的測試環(huán)境進行測試，可能會遇到資源監(jiān)控、應用服務器和壓力機等環(huán)境上的各種問題。

監(jiān)控的服務器節(jié)點比較多，一臺Controller是否可以做到，需要在測試過程中評估。

對于測試過程中腳本和參數(shù)化數(shù)據(jù)，是否容易構造，且能夠高效率的構造，否則會消耗太多的時間構造測試用數(shù)據(jù)。

典型交易腳本編寫：

由于上述6個交易類型全部為后臺交易，需要游戲前端調(diào)用產(chǎn)生交易，是無法錄制腳本再增強腳本的。設計有兩種方案，第一種方案是編寫調(diào)用后臺方法，這樣需要開發(fā)提供交易接口，還需要提供鑒權方法，以及hash產(chǎn)生方法。第二種方案是由開發(fā)封裝6個交易方法，只是提供測試調(diào)用接口即可。最后通過商議，開發(fā)決定采用第二種方案。這可能是開發(fā)覺得比較安全的方式。:)

基本賬戶轉賬的訪問代碼如下：

web_set_max_html_param_len("300000");

lr_start_transaction("基本賬戶轉賬300");

web_reg_save_param("txhash2","LB=\"txhash\": \"", "RB=\",\"from\"", LAST );

web_url("ta300.icwv1.co",

"URL=http://192.168.1.12:端口號/tst/pbte.do/",

"TargetFrame=",

"Resource=0",

"RecContentType=text/html",

"Snapshot=t1.inf",

"Mode=HTML",

LAST );

lr_end_transaction("基本賬戶轉賬300", LR_AUTO);

//格式化的往文件fp1中寫字符串

if(strlen(lr_eval_string("{txhash2}"))==64)

fprintf( fp1,"%s\n",lr_eval_string("{txhash2}") );

else

fprintf( fp20,"%s\n",lr_eval_string("{txhash2}") );

上面代碼是運用到每一個節(jié)點。代碼中主要通過注冊函數(shù)獲得訪問基本交易轉賬返回的hash值，把值保存在文件中。該值用例作為基本交易查驗的hash值參數(shù)傳入。每個節(jié)點劃分為一個事務。單獨統(tǒng)計事務各相關性能指標。

腳本處理上沒有技術障礙，主要是請求中支持json報文格式，壓力機寫本地文件，使用了每個交易寫一個文件，減少文件增大時，寫入的速度。且在每個壓力機上分別創(chuàng)建目錄和空間記錄返回值。

在場景設置中，由于并發(fā)量比較大，在加壓過程、減壓過程中注意根據(jù)前面的試運用過程，掌握每個虛擬用戶的初始化時間，減壓時間等，使產(chǎn)生的監(jiān)控曲線更方便度量和處理。

測試執(zhí)行過程：

單交易基準測試，主要是1個虛擬用戶迭代10次獲得各種性能指標，主要是查看響應時間，其它指標一般都不會超過指標要求。通過對6個典型交易的基準測試，調(diào)試好腳本。測試表名，所有指標都OK。

單交易負載測試，主要是單獨對每一個交易做2000并發(fā)用戶測試。為了節(jié)省測試時間，沒有采用每次執(zhí)行并發(fā)用戶遞增方式，而是直接使用2000個并發(fā)執(zhí)行測試。監(jiān)控JVM、服務器的資源使用情況。單交易負載測試，尤其是基本交易轉賬交易，先后執(zhí)行多次，通過該交易評估出每分鐘需要的hash數(shù)，以便后面測試場景設計的執(zhí)行時間來估算構造數(shù)據(jù)量。也通過該交易，評估出達到2000個并發(fā)需要的應用服務器數(shù)量和壓力機數(shù)量。解決資源監(jiān)控和記錄返回報文的解析出hash值的左右邊界以及寫文件方案等。

混合業(yè)務負責測試，6個典型交易采用按照等比例的方式，直接使用2000個并發(fā)用戶進行負載測試，在測試執(zhí)行過程中，出現(xiàn)并發(fā)虛擬用戶無法加載，最多加載達到1669個并發(fā)用戶。監(jiān)控JVM、服務器的資源使用情況。

整個測試執(zhí)行過程，有效的測試場景共14個，6個基準，6個單交易，2個混合。

在測試過程中，發(fā)現(xiàn)的系統(tǒng)問題主要有：

1、TPS呈現(xiàn)多個波峰現(xiàn)象，處理不穩(wěn)定。

通過與加載的虛擬用戶數(shù)量，處理tps以及服務器資源情況判斷，主要是通過監(jiān)控JVM垃圾回收情況判斷得出，每隔10秒左右的垃圾回收正好與生成的tps曲線基本一致。初步分析，JVM年老代一直占滿，而年輕代每隔20秒左右滿，這樣導致年輕代觸發(fā)垃圾回收，在垃圾回收的幾秒內(nèi)，tps降低到幾乎為零。為什么在運行初期，年老代會被占滿呢？這與在構造測試數(shù)據(jù)時可能有關系，每次測試執(zhí)行之前構造上百萬的測試數(shù)據(jù)，這些數(shù)據(jù)構造過程中，占滿了年老代，這可能與開發(fā)團隊采用的構造數(shù)據(jù)代碼使用堆內(nèi)存方式有關系。解決方案是每次構造數(shù)據(jù)后，重新啟動服務器，這樣構造的測試數(shù)據(jù)在文件里，而不是直接在內(nèi)存里，在-Xms和Xmx參數(shù)設定中，都是設定的可使用4G內(nèi)存。這樣解決了該問題，由于生產(chǎn)中，不用在開始時，構造上百萬的測試數(shù)據(jù)，不會造成很短時間內(nèi)進行垃圾內(nèi)存回收。

2、在混合業(yè)務時，后臺日志中拋出并發(fā)超時錯誤。

在混合業(yè)務2000個并發(fā)測試執(zhí)行中，前臺觀察到的大約200多個虛擬用戶由于失敗等原因停止。開發(fā)人員監(jiān)控后臺日志，發(fā)現(xiàn)拋出了大約20個左右的并發(fā)超時異常信息。該問題，在測試之前階段，測試和開發(fā)人員無法分析出問題原因，2000個并發(fā)用戶，分布到10個服務器節(jié)點，每個服務器承擔了約200個并發(fā)用戶，理論上對于16CPU16G內(nèi)存的服務器來說，應該能夠承受。具體原因，需要架構師進行深入分析。

在部署10臺服務器節(jié)點，使用6臺壓力機和1臺Controller進行壓力測試情況下，無法達到2000個并發(fā)，但是TPS能達到20000的要求，響應時間不管是在單交易并發(fā)還是混合交易并發(fā)情況下，都不超過0.2秒的響應時間。交易成功率雖然無法達到100%，但是超過了99.99%，有少量的失敗或停止。增加服務器節(jié)點和壓力機應該可以達到性能要求指標。由于該系統(tǒng)是通過添加服務器節(jié)點來支持更多的并發(fā)用戶數(shù)量，但是有不是線性關系，畢竟每增加一個節(jié)點，其在合約判定上都會增加時間消耗。

測試過程問題：

在測試過程中，曾經(jīng)出現(xiàn)的問題和解決方案如下：

1、壓力機問題，在開始時，單業(yè)務2000個并發(fā)用戶時，會出現(xiàn)虛擬用戶加載時間過長，或用戶中間由于錯誤、超時等原因停止。采取的措施是增加壓力機的方法，由3臺壓力機增加到6臺，這樣controller不再兼做壓力機了，對于服務器性能指標監(jiān)控就更及時一些。

2、監(jiān)控CentOS時，沒有安裝RPC服務。通過下面方法安裝RPC服務，安裝后，啟動3個服務解決。

Step 1 安裝RPC相關程序

執(zhí)行命令：yum install inetd，這一步是為了安裝rstatd的守護進程
執(zhí)行命令：yum install rusers-server

Step 2 啟動服務

service rpcbind start

service xinetd start

service rstatd start

3、構造測試用例數(shù)據(jù)

測試過程中，比較麻煩是進行大量交易hash值的構造，該值本來應該是在客戶端每次調(diào)用服務時產(chǎn)生，而現(xiàn)在是需要在進行執(zhí)行壓力測試之前產(chǎn)生。通過post調(diào)用，在內(nèi)存數(shù)據(jù)庫中產(chǎn)生需要的hash值，只要服務器不重啟，該值一直存在。在下面的post提交的前3個值確定構造3種交易hash的值的數(shù)量。

4、2000個并發(fā)時，Controller出現(xiàn)下面錯誤信息。

Action.c(35): Error -27796: Failed to connect to server "172.17.0.10:38000": [10048] Address already in use.TrychangiACAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters\TcpTimedWaitDelay to 30 and HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters\MaxUserPort to 65534 and rebooting the machine See the readme.doc file for more information

按照提示信息，判斷可能是壓測目標是一個簡單方法調(diào)用，服務器端口數(shù)不夠造成的。根據(jù)上面提示在注冊表中已將壓力機注冊表中的TcpTimedWaitDelay? 改為 1;MaxUserPort 改為 65534；并且重啟電腦，運行壓力仍出現(xiàn)上面的錯誤。之后在 run-time setting/browser emulation中將simulate a new user on each iteration? 選項去掉，重新運行一切正常，不再有錯誤出現(xiàn)。每次迭代不再模擬一個新的虛擬用戶，這樣相當于保持客戶機和服務器連接，也不用每次迭代下載數(shù)據(jù)。具體的原因需要更深入研究Loadrunner本身的機制。

5、在3臺壓力機時，壓力機本身的CPU、內(nèi)存等資源充足，但是模擬的用戶數(shù)量卻上不去？

我們的壓力機安裝的windows sever 2008。在Windows計算機的標準設置下，操作系統(tǒng)已經(jīng)默認限制只能使用大線程數(shù)所導致。修改注冊表可以打開該限制。

(1)HKEY_LOCAL_MACHINE找到：System\CurrentControlSet\Control\Session Manager\SubSystems。
(2)找到下面字段：
%SystemRoot%\system32\csrss.exe bjectDirectory=\Windows
SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1
ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2
ProfileControl=Off MaxRequestThreads=16
其中SharedSection=1024,3072,512格式為xxxx,yyyy,zzz，其中，xxxx定義了系統(tǒng)范圍堆的大值（以KB為單位），yyyy定義每個桌面堆的大小。

(3)將yyyy的設置從3072更改為8192（即8MB），增加SharedSection參數(shù)值。
通過對注冊表的更改，系統(tǒng)將允許運行更多的線程，產(chǎn)生更多的Vuser。另外，也需要調(diào)整Loadrunner本身對壓力機的控制。在loadrunner中，默認的是每50個vuser會使用一個mdrv.exe進程，可以啟動多個mdrv.exe的進程，每個進程中的vuser數(shù)量少一點，具體的辦法如下：安裝目錄下"dat"protocols"CsNet.lrp文件中，在[Vugen]下面新加一條MaxThreadPerProcess=要設置的vuser數(shù)量。這樣每個mdrv.exe進程中的vuser數(shù)量就是設置的數(shù)量。

6、Docker中JVM監(jiān)控問題。

JVM監(jiān)控可以使用JDK自帶的jvisualvm應用監(jiān)控，通過圖形判斷比使用jstat等命令監(jiān)控更方便一些。但是Docker中的JVM外部是訪問不了，所以，我們使用了jvisualvm監(jiān)控了服務器的JVM。Docker內(nèi)部的JVM只能通過命令行，進行監(jiān)控。

7、Loadrunner在大量并發(fā)寫文件問題分析。

在大量并發(fā)用戶執(zhí)行過程中，發(fā)現(xiàn)了Loadrunner寫文件上的問題。在兩個事務中，要把產(chǎn)生的hash值寫入文件中，目的是為了檢查返回的hash值是否正確。發(fā)現(xiàn)在記錄的文件中，大約1%左右的hash值記錄的長度超長或縮短了，Loadrunner在大量的并發(fā)用戶在同時寫一個文件時，是否會出現(xiàn)，一個線程時間片寫不完，下個時間片再寫導致出錯呢？或者是系統(tǒng)在返回hash只上面就有問題。解決方法是在寫文件時，首先對根據(jù)左右邊界找到的hash值進行長度判斷，如果長度等于要求的長度64，則寫入，否則不寫文件。這樣再次執(zhí)行寫入文件時，發(fā)現(xiàn)還是會出現(xiàn)超過64個字符長度或縮短的問題，是否是loadrunner本身的問題，需要后續(xù)研究。在后面的調(diào)用查驗事務時，直接通過關聯(lián)把hash值插入，也不會出現(xiàn)hash值不正確問題。

8、在對運用區(qū)塊鏈技術的系統(tǒng)性能測試中，出現(xiàn)了很多問題，有些沒有在上面列出，例如，京東云的不穩(wěn)定，騰訊云的不穩(wěn)定，最后換成阿里云，應用服務器和壓力機才比較穩(wěn)定下來。剛開始時壓力機安裝的Windows sever 2012，作為壓力機限制較多，后面換成阿里云后，全部換成Windows server 2008，遠程桌面連接和rps服務使用起來方便很多。用服務器版本作為壓力機應該不是最佳選擇，但是由于租用的服務器上無Win 7等，所以只能這樣選擇。在測試過程中，開發(fā)人員遇到系統(tǒng)上的問題，也會升級解決，沒有把問題全部匯總出來。

測試中的不足，由于沒有參與進行功能測試，只是根據(jù)性能指標要求進行壓力負載測試，所以對于驗證數(shù)據(jù)的返回，但是沒有驗證返回數(shù)據(jù)的正確性。由于對于云服務器的使用，包括應用服務器和壓力機，都是第一次使用，對于系統(tǒng)支持并發(fā)用戶的數(shù)量提前沒有估計，所以對于為達到TPS和并發(fā)用戶數(shù)，有一個試探性的過程，消耗了時間。感覺基于云的服務與物理的服務器在性能上還是會存在較大差距。

下面貼幾張監(jiān)控得到的圖，以供了解。

2000并發(fā)時，TPS圖，截取持續(xù)壓力期間的圖形

2000用戶并發(fā)時，各應用服務器上的資源監(jiān)控

1600和2000個并發(fā)用戶時，出現(xiàn)的并發(fā)超時日志截圖：

(完)

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

當前文章：基于區(qū)塊鏈技術的性能測試-創(chuàng)新互聯(lián)
分享網(wǎng)址：http://m.jiaotiyi.com/article/codcii.html