当前位置:网站首页>Performance testing and tuning practice based on fabric

Performance testing and tuning practice based on fabric

2020-11-12 15:24:05 Huawei cloud developer community

Abstract : This article focuses on Fabric The core business , Build a test model , Native to the community Fabric And Huawei cloud blockchain ( be based on Fabric) Carry out the actual measurement , Identify community natives Fabric Performance bottlenecks , And try to use the dynamic scaling provided by Huawei blockchain 、 Fast PBFT The algorithm is optimized , Improve several key metrics .

1、Fabric Performance testing status

In layman's terms , Blockchain is a kind of chained data structure that combines data blocks in chronological order and connects them in order , Distributed ledger guaranteed by cryptography . The currency (Bitcoin)、 The etheric fang (Ethereum)、 Super ledger (Hyperledger) They are all typical blockchain systems . among Hyperledger Fabric Is the most popular enterprise blockchain framework ,Fabric A loosely coupled design , The consensus mechanism 、 Authentication and other components are modular , In the application process, it is convenient to select the corresponding module according to the application scenario .

Fabric Performance is one of the most concerned issues for users , However , At present, there is no authority neutral agency , According to accepted rules , Yes Fabric Carry out performance test and give test report , There are probably several reasons :

(1)Fabric Still in rapid development , Detailed neutral and accepted test rules have not been given ;

(2)Fabric Network structure ( network bandwidth 、 disk IO、 Computing resources, etc ), Configuration parameters ( Such as block size 、 Endorsement strategy 、 Number of channels 、 State database, etc ), Consensus algorithm (solo,kafka,pbft etc. ) Will affect the evaluation results , It's hard to build a reflection fabric The whole picture of the test model ;

(3)Fabric The transaction process is complicated , There are many differences between traditional databases , It also doesn't apply to traditional testing programs and tools ;

This article focuses on Fabric The core business , Build a test model , Native to the community Fabric And Huawei cloud blockchain ( be based on Fabric) Carry out the actual measurement , Identify community natives Fabric Performance bottlenecks , And try to use the dynamic scaling provided by Huawei blockchain 、 Fast PBFT The algorithm is optimized , Improve several key metrics .

2、Fabric Transaction process analysis

stay Fabric During the transaction , Involving different roles , Each role has a different function , node (Peer) It can be subdivided into endorsement nodes (Endorser peer) And submit nodes (Committer peer), Consensus is sorted by (Orderer) Role completion . The transaction process is as follows :

chart 1:fabric Transaction flow chart

(1): Application client through SDK Launch a transaction proposal to the blockchain network (Proposal), The transaction proposal identifies the contract to be called in this transaction 、 The contract method, parameter information and client signature information are sent to the endorsement node (Endorser).

(2): An endorsement node (Endorser) Received a deal proposal (Proposal) after , Verify the signature and determine if the submitter is authorized to perform the action , Execute the smart contract after the validation is passed , The result is signed and sent back to the application client .

(3): The application client receives the endorsement node (Endorser) After the information returned , Judge whether the proposal results are consistent , And whether to refer to the specified endorsement policy , If there is not enough endorsement , Then suspend processing ; otherwise , The application client packs the data together into a transaction and signs it , Send to Orderers.

(4):Orderers Sort the received transactions by consensus , Then according to the block generation strategy , Pack a bunch of deals together , Generate new blocks , Send to the submission node (Committer);

(5): Submit node (Committer) After receiving the block , Each transaction in the block will be verified , Check whether the input and output relied on by the transaction match the status of the current blockchain , After completion, append the block to the local blockchain , And modify the state of the world .

Client pass Fabric Close the deal , There are three steps to perception ( Collect endorsements , Submit sort and confirm results ), And the traditional database reading and writing , Just make a request , Wait for confirmation . If you use classic testing tools such as JMeter, Need to put fabric sdk For packaging RESTFul Interface , Increased the complexity of the evaluation . Fortunately, ,2017 year 5 Monthly super ledger community launched Caliper, Allows users to test specific blockchain technology implementations through a series of preset use cases .Caliper The generated report will contain a series of blockchain performance indicators , Such as TPS( The average number of transactions per second ), Time delay , System resource occupancy, etc . The evaluation results of this paper are Caliper Tools to test the build .

3、Fabric Test model building

Build a performance test model , It mainly includes two parts : One is to extract evaluation indicators according to business characteristics ; The second is to establish a stable and measurable business model .

3.1 Evaluation indicators

Fabric It's a typical distributed system ,Fabric In the network Peer Independent deployment , Maintain your own books separately ( Support endorsement query ), Through internal Gossip Synchronization of communication completion status .Fabric Comply with partition tolerance , According to the distributed system CAP Theorem ,Fabric Under the premise of ensuring availability , There is no way to ensure consistency .Fabric It's through ultimate consistency ( A kind of weak consistency ) To ensure that all nodes finally agree on the state of the world , This process is Orderer Consensus and Peer The process of validation . So in our test model , The following indicators are mainly investigated :

Query throughput (Query Throughput): Number of query requests processed per second

Consensus throughput (Consensus Throughput): The number of consensus requests processed per second

Consistent throughput rate (Consistency Throughput): The number of synchronization services completed per second

Average delay (Avg Latency): The average time taken to complete a transaction

Failure rate (Fail Rate): There was a business failure ( Including overtime ) The proportion of

3.2 business model

In the choice of business scenarios , We think about mainstream scenarios as much as possible , Get rid of options that are bottlenecks in themselves , Focus on the core business of blockchain .

Infrastructure ,Orderer and Peer Node we choose mainstream 8vCPU16G Specifications of virtual machine ,Client Choose one 32vCPU64G Virtual machine of . The whole test is done in a stable subnet .Orderer Node we configure 4 individual , Satisfy 3f+1 The minimum requirement for fault tolerance .Peer Node we configure 1, Expand as much as you need to 5 individual .

In terms of configuration parameters , We use a single channel , Single organization endorsement , State database selection goleveldb. The drop block strategy uses the default policy (2s/4M/500T).

Consensus algorithm , Can choose solo、pbft、kafka.solo The mode is test mode , It can't be used in production .Kafka Pattern a kind of support CFT Fault tolerant consensus algorithm , Performance mainly depends on the plug-in kafka Cluster performance . and pbft Can guard against Byzantine nodes , More extensive application scenarios , It also requires higher performance . thus , This test chooses pbft As a consensus algorithm .

Chain code , We choose what the community offers chaincode_example02 Example , The percentage of business data is very low , At the same time, it can cover the basic use cases of account book reading and writing .

4 、 Measurement and tuning

4.1 Query performance and dynamic scaling

Fabric Query performance is actually an endorsement request .Peer The end mainly contains 3 A process .

(1) check Proposal Signature ;

(2) Check to see if Channel ACL;

(3) Simulate the execution of the transaction and sign the result ;

Code can refer to the community chaincode_example02.

Test Name Succ Fail Send
Rate
Avg
Latency
Query Throughput
1 query 10000 0 962.6tps 0.01s 962tps
2 query 25000 0 2493.5tps 0.07s 2492tps
3 query 50000 0 4992.0tps 6.68s 2503tps

chart 2: Single organization list Peer Query performance of

You can see , A single node (8vCPU,16G) The reading performance of 2500tps about . Observe the monitoring indicators and find ,CPU Usage rate in 70% about , Close to full load , And the memory utilization rate is only 25% about [z(3] . It's not hard to understand , The endorsement process involves a lot of validation 、 Signature work , These are all computationally intensive operations . According to the blockchain CAP The partition tolerance of the theorem , We can scale horizontally within the organization Peer To improve performance . Huawei blockchain has provided this scalability feature , We will peer The number of 5 individual .

chart 3: Huawei BCS The dynamic scaling properties of

Run the test script again , give the result as follows :

Test Name Succ Fail Send
Rate
Avg Latency Query Throughput
1 query 10000 0 971.4tps 0.01s 971tps
2 query 25000 0 2495.8tps 0.01s 2494tps
3 query 50000 0 4977.1tps 0.01s 4974tps
4 query 12000 0 11898.9tps 0.06s 11869tps

chart 4: Huawei BCS Single organization 5Peer Query performance of

You can see , In constant service , Without sacrificing stability , Through the single Peer Dynamic extension is 5Peer. Performance can be improved 4 More than double , The overall throughput exceeds 10000tps, The average delay is only 0.06s.

4.2 Consensus performance and consensus algorithm

Consensus algorithm is the key to improve the performance of consensus . Community fabric v1.0.0-alpha2 Version provides PBFT Consensus is a practical Byzantine algorithm . The practical Byzantine algorithm mainly improves the inefficiency of Byzantine algorithm , The algorithm complexity is reduced from exponential level to polynomial level , It makes Byzantine fault-tolerant algorithm feasible in practical system application .

Let's start with community PBFT Under the consensus test :

Test Name Succ Fail Send Rate Avg
Latency
Consensus
Throughput
Consistency
Throughput
1 invoke 1000 0 959.5tps 5.53s 574tps 518tps
2 invoke 2000 0 1996.4tps 14.84s 567tps 520tps
3 invoke 5000 0 4889.8tps 37.90s 579tps 503tps

chart 5: Community origin PBFT Consensus performance

You can see , Community native PBFT Consensus , Whether it's throughput , Or average delay , They're all poor . Huawei PBFT The algorithm has Early-Stopping nature , That is, when there is no Byzantine node , The whole network will soon reach a consensus , So the speed should be very fast . We switch to Huawei fast PBFT Consensus algorithm , Let's measure it again :

Test Name Succ Fail Send Rate Avg
Latency
Consensus
Throughput
Consistency
Throughput
1 invoke 10000 0 973.6tps 1.32s 970tps 917tps
2 invoke 20000 0 1976.5tps 1.24s 1971tps 1789tps
3 invoke 50000 0 4995.4tps 4.21s 4985tps 1677tps
4 invoke 100000 0 11133.2tps 9.91s 11031tps 1502tps

chart 6: Huawei BCS Fast PBFT Consensus performance

Switch to Huawei PBFT After algorithm , Consensus throughput can reach 10000tps, Consistent throughput is also close to 1800tps. meanwhile , Relative to the community native version , The average delay is also greatly reduced . This write performance is comparable to the traditional single node relational database , It can satisfy most business scenarios .

4.3 About final consistency

In the process of testing consensus performance , We find that when consensus throughput exceeds 2000 when ,Peer There is a backlog when synchronizing blocks , This leads to an increase in the average delay . To understand in detail why , You can refer to Fabric Key source code (gossip/state/state.go) To get to know Peer The process of falling blocks :

chart 7:gossip Synchronous block flow chart

stay fabric in , The book data is mainly made up of GossipStateProvider adopt Gossip Protocol to synchronize , Only the key process can be given here .

(1) Start a process deliverPayloads from orderer Or other Peer obtain “ Blank pieces ”, call LegerResources.StoreBlock;

(2) LegerResources call Validator Verify that the transaction complies with the endorsement strategy , Check whether the version in the read set is consistent with the ledger ;

(3)LedgerCommittor Execute legitimate transactions in blocks , Update ledger status ;

(4)ServiceMediator Update channel metadata ;

The author modified the source code , Added 4 Time consuming statistics of the steps , Results show 40000 Transaction generation 200 In the case of blocks , step 2( check ) Time consuming 17s, And steps 3( Write a piece , Update index ) Time consuming 40s. Both occupy deliverPayloads 80% Time consuming , Guess is the bottleneck of consistent throughput . Turn on Profile After the model , Monitor stack calls , This conjecture is further verified .[z4]

chart 8:gossip Synchronization block Profile Flame chart

The optimization scheme that the author can think of :

(1) Use a high-speed read-write disk (SSD), Improve the reading and writing efficiency of block files ;

(2)Validator Verification is computationally intensive , Can we use the combination of hardware and software , Greatly improve the verification efficiency ;

(3) at present Gossip Get Payload After the data , It can only be processed one by one in series . Whether it can be partitioned according to the read-write set of the block , Give it to different threads , Finally, merge them and put them on the plate , To improve performance ( The reference multichannel performance is times that of a single channel );

I learned through the media that , Huawei blockchain and other product teams , People have been invested in this field for preliminary research , Looking forward to the early release of commercially available products , Give back to the community .

5、 summary

Fabric As the most popular enterprise blockchain solution , It has been successfully applied in many fields . In this test tuning , Discover community Nativity Fabric There are many limitations , If it is not easy to expand , Poor performance , It is not recommended to be used directly in the production environment .

The scalability and speed of Huawei blockchain PBFT Algorithm , It can improve quickly Fabric Trading performance . Among them, the retraction characteristic , You can take it all the time , Improve query performance to 10000tps above ( single peer Of 4 More than double ). And fast PBFT Algorithm , Consensus throughput can be increased to 10000tps above ( Community native 20 times ), It can satisfy most business scenarios .

Simultaneous discovery , In the case of high concurrency , Finally, the average delay of consistency will increase , The main reason is that the current block check and drop disk are executed in sequence , Unable to make full use of multi-core resources . If a community successor or a commercial company , It can be combined with hardware and software , The idea of partition merging , Improve consistent throughput , Reduce delay ,Fabric Will be more successful in the business world .

6、 Reference material

https://hyperledger-fabric.readthedocs.io

https://github.com/hyperledger/caliper

https://github.com/hyperledger/fabric

https://github.com/yeasy/hyperledger_code_fabric

Performance Benchmarking and Optimizing Hyperledger Fabric.pdf

Click to follow , The first time to learn about Huawei's new cloud technology ~

版权声明
本文为[Huawei cloud developer community]所创,转载请带上原文链接,感谢

随机推荐