在尝试使用IBM团队在文章_2637341中报告的Hyperledger Fabric实现性能时，我遇到了一些问题和错误 . 我收集了所有有用的信息，并希望与HF社区分享 . 另外，我向Fabric开发人员提出了一些关于其性能的问题 .
目标说明
在四个c5.9xlarge（36vCPU）aws实例上使用Cello部署Hyperledger Fabric v1.1.0网络：
{
fabric001: {
cas: [],
peers: ["anchor@peer1st.main"],
orderers: ["orderer1st.orderer"],
zookeepers: ["zookeeper1st"],
kafkas: ["kafka1st"]
},
fabric002: {
cas: [],
peers: ["worker@peer2nd.main"],
orderers: ["orderer2nd.orderer"],
zookeepers: ["zookeeper2nd"],
kafkas: ["kafka2nd"]
},
fabric003: {
cas: [],
peers: ["worker@peer3rd.main"],
orderers: ["orderer3rd.orderer"],
zookeepers: ["zookeeper3rd"],
kafkas: ["kafka3rd"]
},
fabric004: {
cas: ["ca1st.main"],
peers: [],
orderers: ["orderer4th.orderer"],
zookeepers: ["zookeeper4th"],
kafkas: ["kafka4th"]
}
}
TLS已禁用 .
Fabric通道配置（所有其他参数是默认值）：
BatchTimeout: 1s
BatchSize:
MaxMessageCount: 500
AbsoluteMaxBytes: 200 MB
PreferredMaxBytes: 50 MB
我将CouchDB和LevelDB的测试作为状态数据库进行了测试 . 我使用官方Fabcar链码（Golang实现）进行测试 . 我创建了简单的nodejs应用程序，它使用SDK与Fabric网络交互，并公开HTTP API进行负载测试 . 这个应用程序是无状态的，可以轻松扩展 . 对于负载测试，我使用的是YandexTank工具 . 我用高负载执行了两种测试：查询（当区块链为空时，通过peer001向Fabric状态请求）和插入（区块链内的事务） .
结果
CouchDB作为状态数据库
-
Query results ：https://overload.yandex.net/101153 . 在~1100 rps时，延迟开始增加 . 但Fabric实例未加载并且拥有大量免费资源 . 在下图中，您可以在测试期间查看实例fabric001上Fabric网络容器的CPU和内存使用情况 . 100％CPU使用率意味着一个完整的vCPU负载 .
peer001打印了很多类似的错误日志（不是完整输出，只是很小的部分，如果需要，我可以与你分享）：https://gist.github.com/krabradosty/9780cacc92fcdeaa0c36377a91727ade -
Insert results ：https://overload.yandex.net/101217 . 在~600 rps时，延迟降低非常快 . 之前是缓慢的，但无论如何，存在 . fabric003容器的CPU和内存使用情况如下图所示：
来自对等体的大量错误日志（同样，未完全输出）：https://gist.github.com/krabradosty/3810151b8e101d8279cc705aef22863e
基于此，我可以得出结论，Fabric Peer在负载下的CouchDB连接存在问题 .
My questions: Fabric的comminity知道这个bug吗？你有计划如何解决它？
LevelDB作为状态数据库
-
Query results ：https://overload.yandex.net/102035 . Fabric001容器的CPU和内存使用情况如下图所示：
区块链没有任何错误，我只看到延迟降级 . -
Insert results ：https://overload.yandex.net/102040 . Fabric001容器的CPU和内存使用情况如下图所示：
激进的延迟降级从~850 rps开始 . 区块链没有错误 .
My questions: 这种延迟降级的原因是什么？为什么我在他们的文章中无法达到IBM报告的3500 rps性能？ Fabric社区在提高性能方面有哪些计划？
1 回答
Fabric是一个排队系统 . 在高负载下，等待时间呈指数级增长（排队属性），从而导致事务延迟 . 但是，对于golevelDB，我们应该以低延迟获得至少2000 tps .
从CPU利用率图看，36个vCPU中只有16个vCPU被充分利用 . 为每个对等体在core.yaml中为validatorPoolSize设置了什么值？您可以将此值设置为等于或小于块大小，并检查吞吐量是否增加 .
表现会有所不同
工作量（fabcar vs fabcoin），
disk（hdd vs ssd，local vs network attached），
负载生成器（CLI vs SDK），
负载生成方法（open system vs closed system vs某些分发）和
网络带宽（2700 tps至少为1.6 Gbps） .
此外，确保负载生成器不会成为瓶颈 . 最好将延迟划分为（认可延迟，排序延迟，提交延迟）并收集其他资源利用率（如网络和磁盘），以便轻松识别瓶颈 .
您可以参考我们的技术论文Performance Benchmarking and Optimizing Hyperledger Fabric . 我们进行了全面的实证研究 . 使用levelDB，我们应该以低延迟获得至少2000 tps .