Hyperledger织物的性能测试

Question

在尝试使用Hyperledger Fabric实现性能时,IBM团队在他们的文章Hyperledger Fabric:Permissioned Blockchains的分布式操作系统中报告过,我遇到了一些问题和错误.我收集了所有有用的信息,并希望与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 comminity知道这个bug吗？你有计划如何解决它？

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中为validatorPoolSize设置了什么值？您可以将此值设置为等于或小于块大小,并检查吞吐量是否增加.

表现会有所不同

1. 工作量(fabcar vs fabcoin),
2. 磁盘(hdd vs ssd,本地vs网络连接),
3. 负载生成器(CLI vs SDK),
4. 负载生成方法(开放系统与封闭系统与某些分配)和
5. 网络带宽(2700 tps至少为1.6 Gbps).

此外,确保负载生成器不会成为瓶颈.最好将延迟划分为(认可延迟,排序延迟,提交延迟)并收集其他资源利用率(如网络和磁盘),以便轻松识别瓶颈.

您可以参考我们的技术论文,题为性能基准测试和优化Hyperledger Fabric.我们进行了全面的实证研究.使用levelDB,我们应该以低延迟获得至少2000 tps.