文章Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains中的Hyperledger社区显示，在某些流行的部署配置中，Fabric实现了每秒超过3500个事务的端到端吞吐量。我正在尝试在项目中实现这一目标，但距离目标还很远。在这里，我报告了我的负载测试的第一个结果，并邀请您参加有关如何使用Hyperledger Fabric和Composer实现高吞吐量的调查
项目说明
我们构建使用Hyperledger Fabric的高负载服务。我们的后端系统包括HF区块链网络，几个通过Hyperledger Composer与区块链进行通信的微服务(节点js)，用于微服务之间进行通信的消息代理。
Hyperledger Fabric v1.1。 Hypeledger Composer v0.19.0
光纤网络(与大提琴一起部署):
{
fabric001: {
cas: [],
peers: ["[email protected]"],
orderers: ["orderer1st.orderer"],
zookeepers: ["zookeeper1st"],
kafkas: ["kafka1st"]
},
fabric002: {
cas: [],
peers: ["[email protected]"],
orderers: ["orderer2nd.orderer"],
zookeepers: ["zookeeper2nd"],
kafkas: ["kafka2nd"]
},
fabric003: {
cas: [],
peers: ["[email protected]"],
orderers: ["orderer3rd.orderer"],
zookeepers: ["zookeeper3rd"],
kafkas: ["kafka3rd"]
},
fabric004: {
cas: ["ca1st.main"],
peers: [],
orderers: ["orderer4th.orderer"],
zookeepers: ["zookeeper4th"],
kafkas: ["kafka4th"]
}
}
fabric001-004-t2.xlarge类型的AWS ec2实例最初，我使用m5.4xlarge，但是它花费很多，即使Fabric开始出现故障，CPU使用率也始终很低。
结构配置:
BatchTimeout: 0.2s
BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 98 MB
PreferredMaxBytes: 512 KB
TLS已禁用。
如果需要，我可以使用任何配置执行新测试。
负载测试
首先，我决定测试针对分类帐(CouchDB)状态的请求。区块链是空的，只有系统数据，参与者很少。对CouchDB开放端口的直接查询请求非常快(〜150 ms)。我的微服务通过为现有身份建立永久连接来连接到Fabric。在我们的系统中，请求占用大约500毫秒，而没有高负载。此时间的一半用于消息代理(AWS SQS确实很慢)。对于负载测试，我使用的是YandexTank工具。负载运行顺利，而延迟没有增加到每秒约70个请求。然后，延迟统计数据下降，并且在某些时候，链码开始返回错误消息。您可以在此处查看测试结果:
TEST RESULTS
我在负载测试的迭代过程中收到两种错误消息:
1.
2.
Chaincode容器本身不会重新启动，但是从现在开始它无法正常工作。有时我无法ping通，有时可以，但是无论如何延迟都是可怕的。仅重新启动对等容器可以提供帮助。 (我提醒您，由于Composer，对分类帐的请求通过了一个同级，这不好，但这不是我调查的重点)。
第二个错误真的很奇怪，因为这是我使用的唯一身份，并且在链码开始失败之前就可以使用。它在我重新启动对等后有效。
在施加负载期间，对等方，chaicode和CouchDB的CPU使用率最高(如预期)。我正处于针对我的区块链网络的配置监控系统的中间，不久我将能够共享更多信息。
有什么想法吗？
更新＃1
建议我使用c *类型的AWS实例来部署Fabric。我为测试选择了c5.4xlarge(16 vCPU)。另外，我对Fabric配置进行了一些更改:
BatchTimeout: 1s
BatchSize:
MaxMessageCount: 20
AbsoluteMaxBytes: 98 MB
PreferredMaxBytes: 512 KB
我执行了相同的测试，但令我遗憾的是，我得到了相同的结果:
TEST RESULTS
在下图中，您可以看到持续1分钟的测试期间容器CPU使用率的图表
总的CPU使用率最大约为30％。因此，我们可以看到延迟降低的问题在其他地方。
更新＃2
由于性能结果非常差，我决定继续使用纯净 Fabric 进行测试，而没有任何不必要的中间组件。只是Fabric网络和nodejs SDK。查看新报告here
最佳答案
我使用类似的设置进行了类似的测试，并且使用8个对等节点(单个Org)可以达到约220 RPS。对于第二组织，这种性能肯定会下降。我使用了织物 sample 随附的高性能chaincode。不知道他们如何设法获得3500 RPS。
关于load-testing - 尝试在Hyperledger Fabric网络中实现高吞吐量，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/49875309/