Hyperledger Fabric 的性能测试

Posted 2023-02-18

【中文标题】Hyperledger Fabric 的性能测试

【英文标题】：Performance Test of the Hyperledger Fabric

【发布时间】：2018-10-24 08:38:22

【问题描述】：

在尝试使用 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: ["[e-mail]"],
      orderers: ["orderer1st.orderer"],
      zookeepers: ["zookeeper1st"],
      kafkas: ["kafka1st"]
    ,
    fabric002: 
      cas: [],
      peers: ["[e-mail]"],
      orderers: ["orderer2nd.orderer"],
      zookeepers: ["zookeeper2nd"],
      kafkas: ["kafka2nd"]
    ,
    fabric003: 
      cas: [],
      peers: ["[e-mail]"],
      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 社区对提高性能有什么计划？

【问题讨论】：

出于好奇……你能用最新的master重复levelDB实验吗？ :)

是不是我必须自己构建docker镜像？我可以稍后再试，但我需要开发人员提供的一些信息。我可以只从 master 构建 Peer 映像并将其与 1.1.0 版本的其余 Fabric 元素一起部署吗？

是的，您可以通过获取最新的主分支并运行“make unit-test”在本地构建图像

前 2 张图片看起来像是来自实例 fabric003，而不是描述中所述的 fabric001。是这样吗？

@DmitryPugachev 你好！不确定您是否在几个月后再次重复测试。想看看它是否有所改善

【参考方案1】：

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

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

性能会有所不同

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

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

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

【讨论】：

@senthilnathan 感谢您的回答，非常感谢。也许您可以说几句关于 CouchDB 作为状态数据库的内容？

@DmitryPugachev :) 由于 golevelDB 是一个嵌入式数据库，与 CouchDB 相比，我们获得了更多的吞吐量。使用 CouchDB 作为 stateDB，对于每个 get/putState，peer 需要通过安全的 HTTP 发出 GET/POST REST API 调用。结果，性能下降。我们使用 CouchDB 获得了最大 700 tps。详细答案请参考上述论文的V.D、VI.C、VI.D部分。

@senthilnathan 这太棒了！测试期间使用了哪个 Hyperledger Fabric 版本？本文档是否有最新版本？谢谢。