Question

在文章Hyperledger Fabric: A Distributed Operating System for Permissioned 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 config：

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

[Hyperledger-Composer] undefined：HLFQueryHandler：queryChaincode（）查询有效负载返回错误：错误：2 UNKNOWN：执行错误 chaincode：执行事务失败：超时到期时执行交易

2

LFQueryHandler：queryChaincode（）查询有效负载返回错误：错误：2 UNKNOWN：执行chaincode时出错：返回的事务是失败：错误：当前标识，名称为＆＃39; txBuilder＆＃39;和标识符＆＃39; 5606acbada327a8ef33134e601f990076872b31a3dda5ec0a983e04915d16007＆＃39 ;, 尚未注册？

Chaincode容器本身不会重启，但从这时起它就不能正常工作。有时我无法对它进行ping操作，有时我可以，但无论如何延迟都很糟糕。只有重启对等容器才有帮助。（我提醒你，由于作曲家，对分类帐的请求是通过一个同行进行的，但这并不好，但这不是我调查的重点）。第二个错误真的很奇怪，因为这是我使用的唯一身份，它在链码开始失败之前有效。它重启同行后就可以了。

在应用负载期间，对等体，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进行测试而不需要任何不必要的中间组件。 Just Fabric网络和nodejs SDK。查看新报告here

Answer 1

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

Answer 2

首先，您拥有多少个同伴会影响TPS结果。如果您有更多的同行，几乎总是更好。（但这实际上取决于策略等等...许多其他事情）

第二个批处理大小，超时，消息计数也很重要。如果您需要更高的TPS，则可能需要更大的大小和更高的消息数（例如100）

似乎Java SDK比Node SDK快一点。但是我自己还没有证实。虽然有可能超过1000TPS。（<<<<确认本人）

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

项目说明

负载测试

更新＃1

更新＃2

2 个答案: