Re: What is the best practice in deploying chaincode over peers? #fabric-peer
Hyperledger Fabric performance is tricky, it is important to tune some components.
The main one is the chaincode endorsing policy, if it requires endorsing from all channel orgs, the transaction throughput will suffer.
But other issues should be watched such as:
- Optimize chaincode method
- CouchDB indexes
- Chaincode programming language (Go is fastest)
- Segregation of peers, ordereres and clients in different VMs.
- Batch transaction request other than waiting the complete orderer submit response for each one (event hub may take time)
- Load balancing for clients and endorsing peers
We made some performance experiments changing endorsing policies, clients, and other. You may see the results here:
Regards,
Marcos Sarres | CEO | +55 61 98116 7866
De: fabric@... <fabric@...> Em nome de BigBang019
Enviada em: terça-feira, 18 de janeiro de 2022 04:08
Para: fabric@...
Assunto: [Hyperledger Fabric] What is the best practice in deploying chaincode over peers? #fabric-peer
Background:
In fabric, peers are responsible for endorsement, validation and commit, but those who don't have chaincode can not be selected as endorsers. For example, I have peer0.org1 and peer1.org1 in organization Org1, and peer0.org2 and peer1.org2 in organization Org2. They all joined the channel mychannel, but only peer0.org1 and peer0.org2 have chaincode. In this case, if the the endorsement policy of a chaincode is set as default, i.e. magority endorsement, the workload of peer0.org1 and peer0.org2 is heavy because they have to endorse 100% tx.
So I wonder:
In a Fabric network, the percentage of those who have chaincode can affect the performance of the network. How much of that percentage is the best practice?