尝试在Hyperledger Fabric网络中实现高吞吐量

Question

Hyperledger Fabric:Perveded Blockchains的分布式操作系统文章中的Hyperledger社区显示,在某些流行的部署配置中,Fabric实现了每秒超过3500个事务的端到端吞吐量.我正试图在我的项目中实现这个结果,但我离它很远.在这里,我将报告我的第一个负载测试结果,并邀请您加入调查,了解如何使用Hyperledger Fabric和Composer实现高吞吐量

项目说明

我们构建使用Hyperledger Fabric的高负载服务.我们的后端系统包括HF区块链网络,几个微服务(节点j),通过Hyperledger Composer与区块链通信,消息代理用于微服务之间的通信.

Hyperledger Fabric v1.1.Hypeledger Composer v0.19.0

Fabric网络(与Cello一起部署):

{
    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"]
    }
}

fabric001-004 - t2.xlarge类型的AWS ec2实例.最初,我使用的是m5.4xlarge,但它的成本很高,即使Fabric开始出现故障,CPU使用率也始终很低.

Fabric配置:

BatchTimeout: 0.2s
BatchSize:
    MaxMessageCount: 10
    AbsoluteMaxBytes: 98 MB
    PreferredMaxBytes: 512 KB

TLS禁用.

如果需要,我可以使用任何配置执行新测试.

---

负载测试

首先,我决定测试分类帐状态(CouchDB)的请求.区块链是空的,只有系统数据和参与者很少.对CouchDB开放端口的直接查询请求非常快(~150 ms).我的微服务通过为现有身份建立永久连接来连接到Fabric.请求在我们的系统中占用约500毫秒而无需高负载.这段时间的一半是消息代理(AWS SQS非常慢).对于负载测试,我使用的是YandexTank工具.负载正在顺利进行,没有延迟增加到每秒约70个请求.然后延迟统计信息降级,并且在某些时候,链代码开始返回错误消息.您可以在此处查看测试结果:

检测结果

在负载测试的迭代期间,我收到了两种类型的错误消息:

1.

[Hyperledger-Composer] undefined:HLFQueryHandler:queryChaincode()查询有效负载返回错误:错误:2 UNKNOWN:执行链码时出错:执行事务失败:执行事务时超时到期

2.

LFQueryHandler:queryChaincode()查询有效负载返回错误:错误:2 UNKNOWN:错误执行chaincode:事务返回失败:错误:当前标识,名称为"txBuilder",标识符为"5606acbada327a8ef33134e601f990076872b31a3dda5ec0a983e04915d16007",尚未注册

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

我进行了相同的测试,遗憾的是,我得到了相同的结果:

检测结果

在下图中,您可以看到测试期间容器CPU使用情况的持续时间为1分钟

最大CPU使用率约为30%.所以我们可以看到延迟退化的问题存在于其他地方.

---

更新#2

由于性能结果非常差,我决定继续使用纯Fabric进行测试而不需要任何不必要的中间组件.Just Fabric网络和nodejs SDK.在此处查看新报告

Answer 1

我使用类似的设置进行了类似的测试，使用 8 个对等节点、单个 Org 可以实现大约 220 RPS。对于第二个组织，这种性能肯定会下降。我使用了结构样本提供的高性能链码。不知道他们是如何获得 3500 RPS 的。