解读 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 （ 受测系统的简写：System under Test）事务负载为 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指定执行持续时间+固定提交速率，交易量可计算
所以我们可以看到样例程序的测试结果是这样的

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

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