解读 Caliper 修改配置文件调整交易量进行性能测试（中文首发）

在上一篇文章里【Fabric2.3 使用Caliper进行性能测试（保姆级示范，亲测可行）】，在走通测试样例后，新的问题就产生了：如果我们需要测量不同交易量下的区块链性能，去哪里设置修改呢？本篇Blog将以上面提到的这一篇样例为研究对象，来解决这个问题。

 在这段执行命令里，

npx caliper launch manager \
--caliper-workspace ./ \
--caliper-networkconfig networks/fabric/test-network.yaml \
--caliper-benchconfig benchmarks/samples/fabric/fabcar/config.yaml \
--caliper-flow-only-test \
--caliper-fabric-gateway-enabled

我们看到Caliper的工作路径、网络配置、测试配置，其中路径benchmarks/samples/fabric/fabcar/config.yaml 指定的是测试配置文件。接下来我们预览一下这个config.yaml的文本内容

我们用红框标识出来了这里面用到的两种交易量的设置方式。

接下来我们先认识一下这些参数及其含义

参数	含义
test.name	要在报告中显示的benchmark的短名称。
test.description	要在报告中显示的benchmark的详细说明。
test.workers	与工作线程相关的对象的配置。
test.workers.type	（暂未投入使用）
test.workers.number	指定用于执行工作负载的工作进程数。
test.rounds	对象回合数组，一个数组下可以有多轮不同的测试任务。
test.rounds[i].label	该轮测试的名称，通常对应于该轮要提交的测试的类型。
test.rounds[i].txNumber	应在该轮任务提交的任务数。
test.rounds[i].txDuration	该轮提交任务数的用时（单位，秒）。
test.rounds[i].rateControl	描述该轮的速率控制策略。
test.rounds[i].workload	描述该轮的工作负载模块。
test.rounds[i].workload.module	该轮基准测试工作负载模块实现的路径。
test.rounds[i].workload.arguments	作为配置，传递给该轮工作负载模块的参数

因为我们要调整交易数量，所以我们要对rateControl做进一步了解

fixed-rate

固定速率控制器是最基本的控制器，如果没有指定控制器，它会是默认选项。 它将以指定为 TPS（每秒事务数）的固定间隔发送输入事务。

以 10 TPS 驱动的固定速率控制器通过以下控制器选项指定

{
  "type": "fixed-rate",
  "opts": {
      "tps" : 10
  }
}

fixed-load

固定负载率控制器是用于以目标负载（积压事务）驱动测试的控制器。 该控制器旨在通过修改驱动的 TPS 来维护系统内已定义的事务积压。 结果是系统的最大可能 TPS，同时保持挂起的事务负载。

固定负载控制器旨在保持 SUT （ 受测系统的简写：***S***ystem ***u***nder ***T***est）事务负载为 5，起始 TPS 为 100，通过以下控制器选项指定：

{
  "type": "fixed-load",
  "opts": {
    "transactionLoad": 5,
    "startingTps": 100
  }
}

这里对常用的fix-rate和fix-load做了必要介绍，其他还有很多控制器，不做展开叙述，需要了解的话可以参考官方文档。

做完知识引导，我们接着回来分析前面提到的配置文件

test:
  workers:
    number: 5
  rounds:
    - label: Create a car.
      # 5000 transactions should create around 1000 cars per worker but not guaranteed
      # so need to set asset limits to less than 1000 for the other tests
      txNumber: 5000
      rateControl:
          type: fixed-load
          opts:
            transactionLoad: 5
      workload:
        module: benchmarks/samples/fabric/fabcar/createCar.js
    - label: Change car owner.
      txDuration: 30
      rateControl:
          type: fixed-load
          opts:
            transactionLoad: 5
      workload:
        module: benchmarks/samples/fabric/fabcar/changeCarOwner.js
        arguments:
          assets: 500
    - label: Query all cars.
      txDuration: 30
      rateControl:
          type: fixed-load
          opts:
            transactionLoad: 5
      workload:
        module: benchmarks/samples/fabric/fabcar/queryAllCars.js
        arguments:
          assets: 500
          startKey: '1'
          endKey: '50'
    - label: Query a car.
      txDuration: 30
      rateControl:
          type: fixed-load
          opts:
            transactionLoad: 5
      workload:
        module: benchmarks/samples/fabric/fabcar/queryCar.js
        arguments:
          assets: 500

我们可以读取到这些信息：指定了5名工人，进行了四项测试，分别是“Create a car”、“Change car owner”、“Query all cars”、“Query a car”。以“Create a car”为例，这个指定了交易数为5000，以保持 SUT 事务负载为 5的形式，提交交易。负责执行该任务内容的是createCar.js。然后可以再看“Change car owner”，保持 SUT 事务负载为 5下，这个测试任务要持续30s。

所以，我们从这两个示例可以理解到，在我们介绍的知识背景下。我们可以有下面4种交易量配置组合方式

配置策略	含义
txNumber + fixed-load	指定交易量+固定负载，执行持续时间随机
txNumber + fixed-rate	指定交易量+固定提交速率，执行持续时间可计算
txDuration + fixed-load	指定执行持续时间+固定负载，交易量随机
txDuration + fixed-rate	指定执行持续时间+固定提交速率，交易量可计算

所以我们可以看到样例程序的测试结果是这样的

根据上面的分享，有需要的同学，可以自己对你所需要测试的区块链平台或链码进行自主的配置。勇敢一些，不要怕试错。希望能有所帮助!

更多细节也可以参考这篇文档。