Hyperledger Fabric 的性能测试

Question

在尝试使用 Hyperledger Fabric 实现 IBM 团队在文章 Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains 中报告的性能期间，我遇到了一些问题和错误。我收集了所有有用的信息，并希望与 HF 社区分享。另外，我对 Fabric 开发人员有几个关于其性能的问题。

目标描述

使用 Cello 在四个 c5.9xlarge (36vCPU) aws 实例上部署的 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 channel 配置(所有其他参数均为​​默认值):

BatchTimeout: 1s
BatchSize:
    MaxMessageCount: 500
    AbsoluteMaxBytes: 200 MB
    PreferredMaxBytes: 50 MB

我对 CouchDB 和 LevelDB 作为状态数据库进行了测试。我使用官方 Fabcar 链码(Golang 实现)进行测试。我创建了简单的 Nodejs 应用程序，它使用 SDK 与 Fabric 网络交互，并公开 HTTP API 以进行负载测试。该应用程序是无状态的，可以轻松扩展。对于负载测试，我使用工具 YandexTank。我执行了两种高负载测试:查询(当区 block 链为空时通过peer001向Fabric状态请求)和插入(区 block 链内的交易)。

结果

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 社区知道这个 bug 吗？您有计划如何解决吗？

LevelDB 作为状态数据库

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

我的问题:延迟降低的原因是什么？为什么我无法实现 IBM 在其文章中报告的 3500 rps 性能？ Fabric社区在性能提升方面有什么计划？

Answer 1

Fabric 是一个排队系统。在高负载的情况下，等待时间呈指数增长(排队属性)，从而导致事务延迟。然而，对于 golevelDB，我们应该以低延迟获得至少 2000 tps。

从 CPU 利用率图中，36 个 vCPU 中似乎只有 16 个 vCPU 得到充分利用。 core.yaml 中为每个对等点的 validatorPoolSize 设置什么值？您可以将此值设置为等于或小于 block 大小，并检查吞吐量是否增加。

性能会根据不同的情况而有所不同

1. 工作负载(fabcar 与 fabcoin)，
2. 磁盘(HDD 与 SSD、本地连接与网络连接)，
3. 负载生成器(CLI 与 SDK)，
4. 负载生成方法(open system vs closed system 与某些分布)和
5. 网络带宽(2700 tps 至少 1.6 Gbps)。

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

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