目錄
最近用Caliper測試了以下Hpyerledger Fabric的性能，測試環境用本地的byfn腳本
作爲飯後閒談，這裏我們並不去探究如何提高tps，以及代碼的角度爲什麼會有這樣的區別。
話不多說，代碼：
https://github.com/SamYuan1990/FabriccaliperSample
Caliper性能很差麼？
從觀察到的結果來看，
如果我們僅僅用一個client發起交易的tx，那麼其性能相對於https://github.com/guoger/stupid.git 直接通過GRPC發起請求的對比來看會低，
那麼，真的是caliper用nodejs，以及fabric nodejs sdk的性能很低麼？
我們增加client的數量，可以看到Caliper也可以達到200TPS的。
| Item | TPS |
| Caliper 1 client | 56.6 |
| stupid |
231 |
| Caliper 10 client | 194.3 |
Client可以無限增加麼？
我們把client增加到多個看一下結果
| Item | TPS |
| Caliper 10 client | 194.3 |
| Caliper 15 client |
191.4 |
| Caliper 20 client | 176.8 |
| Caliper 30 client | 130.1 |
我們可以看到隨着client的增加，tps並不是無限增高的，Avg Latency不斷提高。https://github.com/SamYuan1990/FabriccaliperSample/blob/master/result.md
Calliper的rate？
目前我們都是用的fixed-rate, 那麼fixed-feedback-rate，fixed-backlog中unfinished_per_client的選項呢？
從試驗結果來看，個人感覺是unfinished_per_client是對於性能測試進行微調。正如https://hyperledger.github.io/caliper/vLatest/rate-controllers/中描述的那樣
“100 unfinished transactions for each client”
允許每個client有多少個未完成的請求的樣子。如果這個值小於send rate，那麼發送的tps就會低於send rate。如果大於等於，那麼這裏tps就會略高於未設置的fixed-rate。
補充一個結論
使用cliaper做性能測試時，需要根據測試結果，謹慎的優化測試方案。來得到相對好的性能。
Hyperledger Fabric性能測試相關文章總結（個人向）