CODEWITHSUNDEEP
performancehyperledger-fabrichyperledger
andre
andre

Reputation: 329

Hyperledger TPS

I am doing a Proof of Concept (PoC) based on Hyperledger Blockchain and integrating it with healthcare data (it is an academic project).

I followed this tutorial: https://github.com/IBM/BlockchainNetwork-CompositeJourney

Since I am a Windows user and I had no free space left on my SSD to accommodate a Linux Ubuntu dual boot with all ledger stuff, I decided to go with all the POC installation on an "Oracle VM VirtualBox" having all VM files (*.vdi) hosted on my secondary hard drive which is an HDD, not SSD.

That's the tricky part, the "Oracle VM VirtualBox" software itself is installed in my SSD perfectly, but the Linux VM with all the POC is on HDD, which is my secondary hard-drive.

So far I have the Peer working on my VM, and already persisted data on it. My issue/concern is regarding its performance...

I have created a snippet of code in python to benchmark it and I got fabric responses between 2 and 3 seconds per transaction, which I consider an extremely low TPS (Transactions per second) right?

Did I do something wrong? I followed the tutorial step by step, and it is working, but extremally low-performance TPS.

May it be because I have it working on HDD with an Oracle VM?

If I had it all running directly on a SSD with Linux would I get better TPS?

 //composer-rest-server endpoint
 url = 'http://localhost:3000/api/Member'

 start = time.time()
 response = requests.post(url, headers=headers, data=data)
 end = time.time()
 timeTotal = (end - start)

Upvotes: 0

Views: 2214

Answers (2)

PAVAN
PAVAN

Reputation: 771

Generally, TPS in fabric depends on a various factor.

  1. Endorsement Policy (Number of endorsing node and policy)
  2. Current state Database(Level DB, Couch DB)
  3. Resource allocation (Hardware configuration)
  4. Block size(Batch size and Batch time (Defined in configtx.yaml file)) and many more factor

The number of transaction that a network can handle and transaction latency are two different things. The time between sending transaction and getting a response is a latency Maximum number of transactions that are getting executed are in second is TPS

Upvotes: 4

Alexander Yammine
Alexander Yammine

Reputation: 558

There exist a lot of factors for low TPS. To make a transaction in Hyperledger Fabric, this goes through several process.

1) Create transaction proposal and send it to all peers endorsement. For example if you have the next policy endorsement:

AND('Org1MSP','Org2MSP')

At least one peer of each org need to endorse the transactions, for every peer you sended the proporsal they will execute the transaction inside the container and check if it is valid, then if it is valid, they will response with status 200 (This is for every one, individualy).

2) Next step is send the transaction proporsal to the orderer, if is the solo-orderer consensus will be fast than kafka-orderer consensus (You can check how it works here). The orderer will create the block and wait few second before send it to each orgs ancho peers. This few second it a very important param in the configtx.yaml file, this is the BatchTimeout, i will quote the definition of the official site of hyperledger fabric:

Batch Timeout. The amount of time to wait after the first transaction arrives for additional transactions before cutting a block. Decreasing this value will improve latency, but decreasing it too much may decrease throughput by not allowing the block to fill to its maximum capacity.

Here you can read more.

EDIT: For default, the batchTimeout value its 2sec.

3) Now the orderer will send the block to all ancho peers, and they will broadcast the block to all peers of they own organizations, commiting the block and update the state of the ledger.

Of course, if you computer have a low performance this process will be more slow.

Upvotes: 2

Related Questions