Hyperledger Fabric 的性能测试

Question

在尝试使用 IBM 团队在他们的文章 Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains 中报告的 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 作为状态数据库

• 查询结果： https://overload.yandex.net/101153。 在 ~1100 rps 延迟开始增加。但是 Fabric 实例没有加载并且有很多免费资源。在下图中，您可以看到在测试期间实例 fabric001 上的 Fabric 网络容器的 CPU 和内存使用情况。 100% CPU 使用率意味着一个完整的 vCPU 负载。 peer001 还会打印很多类似的错误日志（不是完整输出，只是一小部分，如果需要我可以与您分享）：https://gist.github.com/krabradosty/9780cacc92fcdeaa0c36377a91727ade

• 插入结果：https://overload.yandex.net/101217。在 ~600 rps 时，延迟下降非常快。以前是慢慢的，但无论如何，是存在的。下图fabric003容器的CPU和内存使用情况： 来自同行的大量错误日志（同样，不是完整输出）：https://gist.github.com/krabradosty/3810151b8e101d8279cc705aef22863e

基于此，我可以得出结论，Fabric Peer 在负载下的 CouchDB 连接存在问题。

我的问题： Fabric 社区是否知道这个错误？你有计划如何解决它？

LevelDB 作为状态数据库

• 查询结果：https://overload.yandex.net/102035。下图fabric001容器的CPU和内存使用情况： 区块链没有任何错误，我只是看到延迟下降。
• 插入结果：https://overload.yandex.net/102040。下图fabric001容器的CPU和内存使用情况： 激进的延迟降级从 ~850 rps 开始。区块链没有错误。

我的问题： 这种延迟下降的原因是什么？为什么我无法达到 IBM 在其文章中报告的 3500 rps 性能？ Fabric 社区对提高性能有什么计划？

Answer 1

Fabric 是一个排队系统。在高负载下，等待时间呈指数增长（排队属性），因此事务延迟。但是，对于 golevelDB，我们应该获得至少 2000 tps 和低延迟。

从 CPU 利用率图中，36 个 vCPU 中似乎只有 16 个 vCPU 被完全利用。在 core.yaml 中为每个 peer 设置了 validatorPoolSize 什么值？您可以将此值设置为等于或小于块大小，并检查吞吐量是否增加。

性能会有所不同

1. 工作负载（fabcar 与 fabcoin），
2. 磁盘（硬盘与固态硬盘，本地与网络连接），
3. 负载生成器（CLI 与 SDK），
4. 负载生成方法（open system vs closed system 与某些分布）和
5. 网络带宽（对于 2700 tps，至少 1.6 Gbps）。

此外，请确保负载生成器不会成为瓶颈。最好将延迟进一步划分为（背书延迟、排序延迟、提交延迟）并收集其他资源利用率，例如网络和磁盘，以便轻松识别瓶颈。

您可以参考我们的技术论文Performance Benchmarking and Optimizing Hyperledger Fabric。我们进行了全面的实证研究。使用 levelDB，我们应该以低延迟获得至少 2000 tps。