Performance Hyperledger织物的性能测试

在IBM团队在其文章中报告的使用Hyperledger Fabric实现性能的过程中，我遇到了一些问题和错误。我收集了所有有用的信息，希望与HF社区分享。此外，我还向Fabric开发人员提出了几个关于其性能的问题

目标描述 Hyperledger Fabric v1.1.0网络使用Cello在四个c5.9xlarge（36vCPU）aws实例上部署：

{
    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已禁用

结构通道配置（所有其他参数均为默认值）：

我将CouchDB和LevelDB作为状态数据库进行了测试。我使用官方的Fabcar链码（Golang实现）进行测试。我创建了简单的nodejs应用程序，它使用SDK与Fabric网络交互，并为负载测试公开httpapi。此应用程序是无状态的，可以轻松扩展。 对于负载测试，我使用工具YandexTank。我在高负载下执行了两种测试：查询（当区块链为空时，通过peer001请求结构状态）和插入（区块链内的事务）

结果 CouchDB作为状态数据库

• 查询结果： . 在约1100 rpm时，延迟开始增加。但是Fabric实例没有加载，并且有很多可用资源。在下图中，您可以看到测试期间实例fabric001上结构网络容器的CPU和内存使用情况。100%的CPU使用率意味着一个完整的vCPU负载。 此外，peer001还打印了许多类似的错误日志（不是完整输出，只是很小的一部分，如果需要，我可以与您共享）：

• 插入结果：。在约600转/秒时，延迟下降非常快。以前是缓慢的，但无论如何，存在。下图中fabric003容器的CPU和内存使用情况： 来自对等方的大量错误日志（同样，不是完整输出）：

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

我的问题： Fabric Community知道这个bug吗？你有计划如何解决这个问题吗

LevelDB作为状态数据库

• 查询结果：。下图中fabric001容器的CPU和内存使用情况： 区块链没有任何错误，我只看到延迟降低
• 插入结果：。下图中fabric001容器的CPU和内存使用情况： 攻击性延迟降低从约850 rpm开始。区块链没有错误

我的问题：

---

延迟降低的原因是什么？为什么我不能达到IBM在其文章中报告的3500 RPM性能？Fabric社区在提高性能方面有哪些计划？

Fabric是一个排队系统。在高负载情况下，等待时间呈指数增长（排队特性），因此事务延迟也随之增加。然而，对于golevelDB，我们应该获得至少2000个低延迟的tps

从CPU利用率图来看，36个VCPU中只有16个被充分利用。在core.yaml中为每个对等方的validatorPoolSize设置了什么值？您可以将该值设置为等于或小于块大小，并检查吞吐量是否增加

性能会因环境而有所不同

工作量（fabcar vs fabcoin）

磁盘（hdd与ssd、本地与网络连接）

负载生成器（CLI vs SDK）

负载生成方法（相对于某些分布）和

网络带宽（2700 tps至少为1.6 Gbps） 此外，确保load generator不会成为瓶颈。最好将延迟进一步分为（背书延迟、订购延迟、提交延迟）和收集其他资源利用率（如网络和磁盘），以便轻松识别瓶颈

---

你可以参考我们的技术论文，题目是。我们进行了全面的实证研究。有了levelDB，我们至少可以获得2000个tps，并且延迟很低

出于好奇。。。你能用最新的主机重复levelDB实验吗？：）难道我必须自己建立docker的形象吗？我可以稍后再试，但我需要开发人员提供一些信息。我是否可以只从主映像构建对等映像，并将其与1.1.0版本的rest Fabric元素一起部署？是的，您可以通过获取最新的主分支并运行“make unit test”本地构建映像前两个映像看起来像来自实例fabric003，不是描述中提到的fabric001。是这样吗？@DmitryPugachev嗨！不确定几个月后你是否再次重复测试。好奇地想看看它有没有improved@senthilnathan谢谢你的回答，我真的很感激。也许你可以说几句关于CouchDB作为一个状态数据库的话？@DmitryPugachev:）由于golevelDB是一个嵌入式数据库，与CouchDB相比，我们获得了更多的吞吐量。使用CouchDB作为stateDB，对于每个get/putState，对等方需要通过安全HTTP发出get/POST REST API调用。结果，性能下降。我们有CouchDB最多700个tps。有关详细答案，请参阅上述文件中的第V.D节、第VI.C节和第VI.D节。@senthilnathan这太棒了！。测试期间使用了什么Hyperledger结构版本？是否有此文档的最新版本？谢谢

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