VPC環境で利用できます。
本章では、Blockchain Serviceノードごとのリソースクォータとノード構成による性能数値の変化をテストした結果を示します。
参考
このテストは、NAVER Cloud Platform環境で構築される Hyperledger Fabricを基準に性能を測定した結果であり、測定結果はテスト Machineのハードウェア性能や Smart Contractの複雑さなど、様々な影響によって異なる場合があります。そのため、当該数値は参考程度にご活用ください。
Hyperledger Fabric財団のテスト結果を確認するには、こちらをご参照ください。
テスト環境
- 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%増加することが確認できます。