最近用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做性能测试时，需要根据测试结果，谨慎的优化测试方案。来得到相对好的性能。
