在尝试使用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状态请求)和插入(区块链内的事务).

结果 …

Hyperledger Fabric:Perveded Blockchains的分布式操作系统文章中的Hyperledger社区显示,在某些流行的部署配置中,Fabric实现了每秒超过3500个事务的端到端吞吐量.我正试图在我的项目中实现这个结果,但我离它很远.在这里,我将报告我的第一个负载测试结果,并邀请您加入调查,了解如何使用Hyperledger Fabric和Composer实现高吞吐量

项目说明

我们构建使用Hyperledger Fabric的高负载服务.我们的后端系统包括HF区块链网络,几个微服务(节点j),通过Hyperledger Composer与区块链通信,消息代理用于微服务之间的通信.

Hyperledger Fabric v1.1.Hypeledger Composer v0.19.0

Fabric网络(与Cello一起部署):

{
    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"]
    }
}

fabric001-004 - t2.xlarge类型的AWS ec2实例.最初,我使用的是m5.4xlarge,但它的成本很高,即使Fabric开始出现故障,CPU使用率也始终很低.

Fabric配置:

BatchTimeout: 0.2s
BatchSize:
    MaxMessageCount: 10
    AbsoluteMaxBytes: …

我有一个文档集合，其中存储了一组数字。该集合大约每 10 秒就会补充新文档。我每天都会运行一个脚本来处理这个数组，并在文档中只留下一个数字。经过 3 个月的数据收集后，我想释放磁盘空间。以下是 Robomongo 集合的统计信息：

{
    "ns" : "orderbook",
    "count" : 5363208,
    "size" : 844457120,
    "avgObjSize" : 157,
    "storageSize" : 2795139072.0,
    "capped" : false,
    "wiredTiger" : {
        "metadata" : {
            "formatVersion" : 1
        }
    }
    "nindexes" : 2,
    "totalIndexSize" : 144482304,
    "indexSizes" : {
        "_id_" : 90615808,
        "date_1" : 53866496
    }
}

正如您所看到的，存储大小远大于大小。我希望该命令compact将释放磁盘空间。

我在 mongo shell 中做什么：

use trading
db.runCommand({compact:'orderbook', force: true})

答案是

{“好的”：1}

来自 /var/log/mongodb/mongod.log 的日志：

2016-12-26T11：19：55.468 + 0300我命令[conn7]紧凑交易。orderbook开始，选项：paddingMode：NONE validateDocuments：1

2016-12-26T11:19:55.562+0300 I 命令 [conn7] 紧凑交易.orderbook …