VPC 환경에서 이용 가능합니다.
이 장에서는 Blockchain Service 노드별 리소스 할당량 및 노드 구성에 따른 성능 수치 변화를 테스트 한 결과를 보여줍니다.
참고
해당 테스트는 NAVER Cloud Platform 환경에서 구축되는 Hyperledger Fabric을 기준으로 성능을 측정한 결과이며 측정 결과는 테스트 Machine 하드웨어 성능 및 Smart Contract의 복잡성 등 다양한 영향에 따라 달라질 수 있습니다. 이에 해당 수치는 참조용으로만 활용해 주십시오.
테스트 환경
- Hyperledger Fabric Version: 2.2.3
- 테스트 Machine 환경
- 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 구성 및 테스트 설정
성능 테스트는 아래 그림과 같이 1개의 Orderer에 2개의 Peer가 있는 Network 구성을 기본적으로 사용하며 Network는 k8s cluster 환경에 노드가 배포되어 있습니다.
- 테스트 도구: Hyperledger Caliper
- 체인코드: Fabcar
- 테스트 네트워크 구성도
성능테스트 Report
1. Orderer/Peer의 리소스 크기에 따른 성능 비교
- Case 1-1
- Orderer: 1대, 0.35 vCPU, 700MB MEM
- Peer: 2대(levelDB), 1.1 vCPU, 2.8GB MEM
| 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대, 1.75 vCPU, 1.4GB MEM
- Peer: 2대(levelDB), 1.1 vCPU, 2.8GB MEM
| 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 |
Case 1-2결과와 같이 Orderer CPU/Memory 리소스 크기에 따라 Case 1-1 대비 write성능이 약 57% 증가함을 확인 할 수 있습니다`
2. Peer CouchDB 사용시 리소스 크기에 따른 성능 비교
- Case 2-1
- Orderer: 1대, 0.35 vCPU, 700MB MEM
- Peer: 2대(1.1 vCPU, 2.8GB MEM), CouchDB 2대 (1 vCPU, 2GB MEM)
| 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대, 1.75 vCPU, 1.4GB MEM
- Peer: 2대(1.1 vCPU, 2.8GB MEM), CouchDB 2대 (2 vCPU, 2GB MEM)
| 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대, 1.75 vCPU, 1.4GB MEM
- Peer: 2대(2.2 vCPU, 2.8GB MEM), CouchDB 2대 (2 vCPU, 2GB MEM)
| 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 |
Orderer, Peer, CouchDB CPU 리소스 크기에 따라서 Write / Read 성능이 향상되는 것을 확인할 수 있으며 LevelDB는 CouchDB 대비 Write성능이 약 +60%정도 차이가 발생할 수 있습니다.
3. Peer 수에 따른 Read 성능 비교
- Case 3-1
- Orderer: 1대, 0.35 vCPU, 700MB MEM
- Peer: 3대(levelDB), 1.1 vCPU, 2.8GB MEM
| 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대, 0.35 vCPU, 700MB MEM
- Peer: 3대(1.1 vCPU, 2.8GB MEM), CouchDB 3대 (1 vCPU, 2GB MEM)
| 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 |
Peer 갯수를 늘리면 각각 case 1-1 , 2-1 대비 Read 성능이 17~22% 증가하는 것을 확인할 수 있습니다.