Blockchain Service benchmark
- Print
- PDF
Blockchain Service benchmark
- Print
- PDF
Article Summary
Share feedback
Thanks for sharing your feedback!
Available in VPC
This chapter shows the result of testing performance figure changes according to the amount of resources assigned for each Blockchain Service node and node configuration.
Note
This test measured performance based on Hyperledger Fabric built in the NAVER Cloud Platform environment, and the measurement result may vary depending on various factors such as testing machine's hardware specification and complexity of the smart contract.
Please use these figures as references only.
Refer to the following page to see the test result by the Hyperledger Fabric foundation.
Test environment
- Hyperledger Fabric Version : 2.2.3
- Test machine environment
- OS : CentOS Linux release 7.3.1611 (Core)
- Processor : Intel(R) Xeon(R) Gold 5220 CPU @ 2.20GHz
- vCPU(s) : 16
- Thread(s) per core : 2
- RAM : 32GB
- HDD : 50GB SSD
Network and test configuration
The performance test uses a network configuration consisting one orderer and 2 peers by default as shown below, and the network has nodes distributed in a k8s cluster environment.
- Test tool: Hyperledger Caliper https://hyperledger.github.io/caliper/
- Chain code: Fabcar https://github.com/hyperledger/fabric-samples/tree/release-2.2/fabcar/go
- Test network configuration image
Performance test report
1. Performance comparison according to resource size of orderer/peer
- Case 1-1
- Orderer: 1 unit, 0.35 vCPU, 70 MB memory
- Peer: 2 units (LevelDB), 1.1 vCPU, 2.8 GB memory
| Name | Success | Fail | Send Rate (TPS) | Max Latency (s) | Min Latency (s) | Avg Latency (s) | Throughput (TPS) |
|---|---|---|---|---|---|---|---|
| Read Transaction | 103543 | 0 | 1725.6 | 0.06 | 0.00 | 0.01 | 1725.4 |
| Write Transaction | 18023 | 0 | 300.4 | 23.23 | 0.05 | 12.74 | 245.6 |
- Case 1-2
- Orderer: 1 unit, 1.75 vCPU, 1.4 GB memory
- Peer: 2 units (LevelDB), 1.1 vCPU, 2.8 GB memory
| Name | Success | Fail | Send Rate (TPS) | Max Latency (s) | Min Latency (s) | Avg Latency (s) | Throughput (TPS) |
|---|---|---|---|---|---|---|---|
| Read Transaction | 104489 | 0 | 1741.4 | 0.05 | 0.00 | 0.01 | 1741.3 |
| Write Transaction | 26699 | 0 | 445.0 | 2.06 | 0.04 | 0.09 | 430.3 |
You can see in case 1-2 that the writing performance increases by approximately 57% depending on the orderer's CPU/memory resource size.
2. Performance comparison according to resource size when using peer CouchDB
- Case 2-1
- Orderer: 1 unit, 0.35 vCPU, 700 MB memory
- Peer: 2 units (1.1 vCPU, 2.8 GB memory), 2 units of CouchDB (1 vCPU, 2 GB memory)
| Name | Success | Fail | Send Rate (TPS) | Max Latency (s) | Min Latency (s) | Avg Latency (s) | Throughput (TPS) |
|---|---|---|---|---|---|---|---|
| Read Transaction | 94280 | 0 | 1571.2 | 4.74 | 0.00 | 0.60 | 1571.0 |
| Write Transaction | 15563 | 0 | 259.3 | 40.67 | 0.08 | 21.72 | 154.7 |
- Case 2-2
- Orderer: 1 unit, 1.75 vCPU, 1.4 GB memory
- Peer: 2 units (1.1 vCPU, 2.8 GB memory), 2 units of CouchDB (2 vCPUs, 2 GB memory)
| Name | Success | Fail | Send Rate (TPS) | Max Latency (s) | Min Latency (s) | Avg Latency (s) | Throughput (TPS) |
|---|---|---|---|---|---|---|---|
| Read Transaction | 98139 | 861 | 1649.8 | 5.66 | 0.00 | 1.39 | 1619.3 |
| Write Transaction | 16718 | 0 | 278.6 | 11.28 | 0.09 | 7.31 | 235.9 |
- Case 2-3
- Orderer: 1 unit, 1.75 vCPU, 1.4 GB memory
- Peer: 2 units (2.2 vCPUs, 2.8 GB memory), 2 units of CouchDB (2 vCPUs, 2 GB memory)
| Name | Success | Fail | Send Rate (TPS) | Max Latency (s) | Min Latency (s) | Avg Latency (s) | Throughput (TPS) |
|---|---|---|---|---|---|---|---|
| Read Transaction | 101933 | 0 | 1698.8 | 0.05 | 0.00 | 0.01 | 1698.6 |
| Write Transaction | 17854 | 0 | 297.5 | 8.01 | 0.08 | 4.44 | 262.6 |
You can see that writing/reading performances are enhanced according to resources sizes of orderer/peer/CouchDB CPU. Writing performance of LevelDB may be differentiated from CouchDB by approximately +60%.
3. Reading performance comparison according to the number of peers
- Case 3-1
- Orderer: 1 unit, 0.35 vCPU, 700 MB memory
- Peer: 3 units (LevelDB), 1.1 vCPU, 2.8 GB memory
| Name | Success | Fail | Send Rate (TPS) | Max Latency (s) | Min Latency (s) | Avg Latency (s) | Throughput (TPS) |
|---|---|---|---|---|---|---|---|
| Read Transaction | 124493 | 0 | 2074.7 | 0.28 | 0.00 | 0.04 | 2073.3 |
| Write Transaction | 18117 | 0 | 301.9 | 33.50 | 0.05 | 17.66 | 237.0 |
- Case 3-2
- Orderer: 1 unit, 0.35 vCPU, 700 MB memory
- Peer: 3 units (1.1 vCPU, 2.8 GB memory), 3 units of CouchDB (1 vCPU, 2 GB memory)
| Name | Success | Fail | Send Rate (TPS) | Max Latency (s) | Min Latency (s) | Avg Latency (s) | Throughput (TPS) |
|---|---|---|---|---|---|---|---|
| Read Transaction | 124110 | 0 | 2068.4 | 0.28 | 0.00 | 0.04 | 2067.4 |
| Write Transaction | 15102 | 0 | 251.7 | 34.40 | 0.10 | 17.89 | 160.1 |
You can see the reading performance increases by 17 to 22% compared to case 1-1 and 2-1 respectively as the number of peers is increased.
Was this article helpful?