现状

目前，主流平台基本支持 Caliper 压力测试。
官方文档：
【1】性能压测工具 Caliper 在 FISCO BCOS 平台中的实践
【2】通过 Caliper 进行压力测试程序
其他个人业务 demo：
【1】基于区块链技术的性能测试
【2】基于 Fabric 的性能测试与调优实践
【3】区块链性能测评实战案例

其他 web 服务器测压思路比如，Apachebench，redisbench，wrk

思路

网络配置
设备配置
redis 截图
1. 查询性能
2. 共识性能
见本子

网络配置

{
  "test": {
    "blockchain": "block-dag",
    "command": {
      "start": "sh block-dag/stress-testing/start.sh",
      "end": "sh block-dag/stress-testing/end.sh"
    }
  },
  "minner": {
    "config": {
      "privateKey": "bcec428d5205abe0f0cc8a734083908d9eb8563e31f943d760786edf42ad67dd",
      "account": "0x64fa644d2a694681bd6addd6c5e36cccd8dcdde3"
    },
    "network": {
      "nodes": [
        {
          "ip": "192.168.1.1",
          "rpcPort": "6001",
          "channelPort": "9001"
        },
        {
          "ip": "192.168.1.2",
          "rpcPort": "6001",
          "channelPort": "9001"
        },
        {
          "ip": "192.168.1.3",
          "rpcPort": "6001",
          "channelPort": "9001"
        }
      ],
      "authentication": {
        "key": "block-dag/stress-testing/sdk/node.key",
        "cert": "block-dag/stress-testing/sdk/node.crt",
        "ca": "block-dag/stress-testing/sdk/ca.crt"
      },
      "timeout": 900000
    }
  }
}

command.start
首先执行 start 配置中指定的命令，主要用于使用 Docker 模式启动，启动 Caliper 时首先执行当前目录下的 start.sh 文件，其具体内容是：

1
2
3

docker -H 192.168.1.1:6001 run -d --rm --name node0 -v /data/test/node0/:/data -p 8000:8000 -p 20914:20914 -p 9001:9001 -w=/data dag/blockdag:latest -c config.ini 1> /dev/null
docker -H 192.168.1.2:6001 run -d --rm --name node1 -v /data/test/node0/:/data -p 8000:8000 -p 20914:20914 -p 9001:9001 -w=/data dag/blockdag:latest -c config.ini 1> /dev/null
docker -H 192.168.1.3:6001 run -d --rm --name node2 -v /data/test/node0/:/data -p 8000:8000 -p 20914:20914 -p 9001:9001 -w=/data dag/blockdag:latest -c config.ini 1> /dev/null

即启动远程的 Docker 容器。
command.end
Caliper 在退出流程的最后会执行 end 配置指定的命令，主要用于清理环境。本例中在测试结束时会执行当前目录下的 end.sh 文件，其具体内容是：

1
2
3

docker -H 192.168.1.1:6001 stop $(docker -H 192.168.1.1:6001 ps -a | grep node0 | cut -d " " -f 1) 1> /dev/null && echo -e "\033[32mremote container node0 stopped\033[0m"
docker -H 192.168.1.2:6001 stop $(docker -H 192.168.1.2:6001 ps -a | grep node1 | cut -d " " -f 1) 1> /dev/null && echo -e "\033[32mremote container node1 stopped\033[0m"
docker -H 192.168.1.3:6001 stop $(docker -H 192.168.1.3:6001 ps -a | grep node2 | cut -d " " -f 1) 1> /dev/null && echo -e "\033[32mremote container node2 stopped\033[0m"

即停止并删除有所的远程容器。
network.nodes
一个包含了所有要连接节点的列表，列表中每一项需要指明被连接节点的 IP 地址、RPC 端口及 Channel 端口号，所有端口号需要和节点的配置文件保持一致。
network.authentication
适配器向节点的 Channel 端口发起请求时需要使用 CA 根证书等文件，这些文件已在 3.1.2 节中调用 build_chain.sh 脚本时已经生成好，使用任一节点配置下的 sdk 文件夹中的相应文件即可，需要在该配置中写上所有文件的路径。

测试配置

---
test:
  name: stress test
  description: This is a stress testing of Block DAG.
  clients:
    type: local
    number: 1
  rounds:
    - label: create
      description: Test performance of creating txs
      txNumber:
        - 15000
      callback: block-dag/stress-testing/create.js
monitor:
  type:
    - docker
  docker:
    name:
      - http://192.168.1.1:6001
      - http://192.168.1.2:6001
      - http://192.168.1.3:6001
  interval: 0.1

测试文件中主要包括两部分：

测试内容配置

test 项负责对测试内容进行配置。配置主要集中在 round 字段中指定如何对区块链系统进行测试。每一个测试可以包含多轮，每一轮可以向区块链发起不同的测试请求。
本次测试是对系统的 createTx 接口进行测试。在测试中，可以通过 txNumber 字段指定测试的交易发送数量

性能监视器配置

monitor 项负责对测试所使用的性能监视器的进行配置。每项配置项的解释如下：

monitor.type，需要指定为 docker，指对 docker 容器进行监控；
monitor.docker.name，一个包含所有要监视的节点的 docker 容器名称列表；
monitor.interval，监视器的采样间隔，单位为秒。

实际测试

实际测试中，我选择类似 Apache 的测试结果。
全是正常交易

Tx Length: 217088 bytes       交易数据的长度
Total Txs Number: 15000
Time taken for tests: 5.919 seconds    所有这些交易发送完所花费的时间
Complete requests: 15000             完成请求数
Failed requests: 0                失败请求数
Write errors: 0
Total transferred: 3256320000 bytes     网络总传输量
TPS: 2536.3 [#/sec] (mean) 吞吐量-每秒交易数
Time per request: 1.513 [ms] (mean, across all concurrent requests) 并发的每个请求平均消耗时间
Transfer rate: 67.15 [Mbytes/sec] received 平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题

说明:
Tx 长度为 212 kb，换算为字节是 217088 bytes

用 nodejs 打印上述结果

打印区块
getMaxHeightBlock 接口–最高块

这里注意到，每个块包含 60 个交易，60*95=5700>3000（为平均每节点分配到的交易量），这里存在几种原因：
① 在并发生成块的时候，由于节点间的速率差异与网络延迟而导致当时观察到的 Tip 集不同，而导致的区块高度高于预期高度。
② 由于处理交易的时候对于放在交易缓存池中的未打包交易进行转发操作，并标记为未打包，导致其中的一些交易被不同的节点重复打包，而导致打包交易量大于预期。