背景

上一周刚好公司有组织参与了 MTSC 2022 年中国互联网测试开发大会(深圳站)，花费了不少的经费去凑了个热闹。当然如果仅仅只是去凑热闹没有收获总结的话，很显然下次领导就不带你们玩了。所以，这里就分享一下开源场《基于HttpRunner 4.0 构建专业级压测工具》的简单实践。那么为什么要分析它呢? 主要还是因为目前IoT服务这块就是基于httprunner这个框架在尝试落地接口自动化，基于一体化的用例设计，接口用例转性能测试用例也及其方便。

---

接口测试->耗时分析?

在做接口自动化之前曾问过一个问题：当页面列表触发点击[查询]按钮到数据返回至页面显示，这中间发生了什么？

在 HTTP 接口测试时，大多数时候只需要关注单个接口整体耗时。那如果测试发现该接口整体耗时较长，我们是否可以更进一步地分析整个http协议过程中那些可能导致慢的原因？

实际上，单次 HTTP(S) 请求是会包含多个步骤的，依次包括 DNS 解析（HOST/LDNS/DNS）、TCP 连接、TLS 握手、服务端处理、数据传输 等5个环节；如果是 HTTP 协议，由于少了 TLS 握手环节，因此会包含 4 个环节。

HttpRunner 从 v4.0 版本开始，新增支持了 HTTP 接口耗时详情的采集能力，可以通过该能力实现对接口整体耗时记性初步的诊断分析。

案例演示

默认情况下，通过 hrp run 执行接口测试时，接口耗时详情信息不会采集。如果要开启，只需要增加一个参数 --http-stat 即可。

hrp run test_downloadOfflinePackages_h5.yaml --http-stat

接口耗时分析

在上面的运行日志中，可以在接口的响应中看到如下信息：

• response 对象详细内容

• 当次 HTTP 请求连接的服务器 IP:Port

• 当次 HTTP 请求的详细耗时

==================== response ====================
Connected via TLSv1.2
HTTP/1.1 200 OK
X-Oss-Server-Time: 2
X-Oss-Storage-Class: Standard
X-Swift-Cachetime: 2183054
X-Swift-Savetime: Mon, 28 Nov 2022 03:35:53 GMT

(response body omitted for Content-Type: application/zip)
--------------------------------------------------

Connected to tcp: 183.232.151.224:443

 DNS Lookup   TCP Connection   TLS Handshake   Server Processing   Content Transfer
[     15ms  |          17ms  |         48ms  |             35ms  |          1085ms  ]
 |                |               |                   |                  |
 namelookup:15ms           |               |                   |                  |
 connect:33ms          |                   |                  |
 pretransfer:81ms              |                  |
 starttransfer:117ms            |
 total:1203ms 

10:26AM INF HTTP latency statistics httpstat(ms)={"Connect":33,"ContentTransfer":1085,"DNSLookup":15,"NameLookup":15,"Pretransfer":81,"ServerProcessing":35,"StartTransfer":117,"TCPConnection":17,"T
LSHandshake":48,"Total":1203}
10:26AM INF validate status_code assertMethod=equals checkExpr=status_code checkValue=200 checkValueType=int64 expectValue=200 expectValueType=int64 result=true
10:26AM INF run step end exportVars=null step="离线包下载" success=true type=api
10:26AM INF run testcase end testcase="h5 离线包下载"
10:26AM INF quit hashicorp plugin process
2022-12-17T10:26:11.096+0800 [WARN]  grpc-py: plugin failed to exit gracefully

结果分析：用例单个接口请求中可以看出，在数据处理返回环节这一块耗费的时间是最久的。那么就可以针对性的进行性能测试。

Summary 结果/HTML报告

如果想将 HTTP 接口耗时详情数据保存为结构化的数据，那我们可以再额外指定 -s 或 --save-tests 参数，即可存储到 summary.json 文件，便于后续对数据采集进行定制化的HTML报告展示。

hrp run test_downloadOfflinePackages_h5.yaml --http-stat  --save-tests

在生成的 summary.json 文件中，会新增一个 httpstat 字段, json文件内容太多就不直接展示

{"httpstat": {
   "Connect": 12,
   "ContentTransfer": 757,
   "DNSLookup": 0,
   "NameLookup": 0,
   "Pretransfer": 33,
   "ServerProcessing": 8,
   "StartTransfer": 42,
   "TCPConnection": 12,
   "TLSHandshake": 20,
   "Total": 799
}}

---

httprunner4.0 性能测试

HttpRunner v4.0 期望成为一款专业级的一体化 API 测试工具，特别是针对性能测试能力进行了重大升级。相比于之前的版本，HttpRunner v4.0 在性能测试部分最大的优化包括如下 4 个方面：

• 使用 Golang 重新实现了脚本执行引擎（基于 Boomer），相比于 Python Locust 提升了发压能力及数据的准确性。

• 对标 LoadRunner 实现丰富的性能测试机制(事务/集合点/思考时间)等。

• 对压测结果进行了严格的 benchmark 测试和数据校准，确保测试结果真实可靠。

• 集成了 Prometheus 性能采集能力，配合 Grafana 可实现丰富的性能指标看板

本次分享会结合一个简单的案例整体介绍如何使用 HttpRunner v4.0 开展性能测试，以便在实际项目中快速上手使用.

性能用例编写

在 HttpRunner 中，得益于「一体化」的特性优势，可以在无需对已有接口测试用例做任何修改的情况下，将测试命令从 hrp run 改为 hrp boom，即可启动性能测试。

config:
  name: 'h5 离线包下载'
  base_url: ${ENV(APP_LOGIN)}
  variables: {}
  exprot:
     - 'ticket'

teststeps:
 -  name: "APP login"
    api: har/login_app.yaml

 -  name: "离线包版本检查"
    api: har/checkH5OfflinePkgUpdate.yaml
    extract:
        h5_url: 'body.data.url'

 -  name: "离线包下载"
    api: har/h5OfflinePackageDownload.yaml

cmd 命令行执行

hrp boom test_ef_login.yaml --spawn-count 100 --spawn-rate 10

另外，HttpRunner v4.0 对标 LoadRunner 新增实现了丰富的性能测试机制，包括「事务」/「集合点」/「思考时间」等，可以在已有的接口测试用例基础上添加特定的步骤进行用例增强。

注意：性能测试的测试用例格式只能选择 (YAML/JSON/GoTest), PyTest 格式底层基于 Python 执行引擎（Locust），考虑到性能和数据准确性问题，目前不再支持性能测试。

添加[事务 Transaction]特性

// 数据结构定义
type Transaction struct {
 Name string          `json:"name" yaml:"name"` // 事务名称: 为任意字符串
 Type transactionType `json:"type" yaml:"type"` // 事务类型: start（事务开始）/end（结束事务）
}

用例中事务示例:

config:
 name: 'h5 离线包下载'
 base_url: ${ENV(APP_LOGIN)}
 variables: {}
 exprot:
 - 'ticket'

teststeps:
 -   name: "APP login"
      api: har/login_app.yaml

 -   name: "离线包版本检查"
     api: har/checkH5OfflinePkgUpdate.yaml
    transaction:  # 定义事务
        name: 'transaction_check'  # 事务名称
        type: start  # 事务开始
    extract:
        h5_url: 'body.data.url'

 -   name: "离线包下载"
    api: har/h5OfflinePackageDownload.yaml
    transaction:
        name: 'transaction_check'
        type: end  # 事务结束

针对「事务」机制，有 2 个需要特别注意的点：

• 使用 HttpRunner v4.0 执行性能测试时，会自动添加名称为 Action 的事务，该事务包含整个测试用例的所有测试步骤（参考了 LoadRunner 的做法）

• 在测试用例中，transaction 应该成对出现，即必须同时定义 start 和 end；如果存在配对缺失的情况，会按照如下逻辑进行处理：

  • 仅设置开始事务，则会在测试用例最后一个测试步后添加结束事务

  • 仅设置结束事务，则会在测试用例第一个测试步前添加开始事务

添加[思考时间]

思考时间可以模拟用户在不同操作间的停顿时间，最大程度还原用户真实的操作行为。

// 数据结构定义
type ThinkTimeConfig struct {
 Strategy thinkTimeStrategy `json:"strategy,omitempty" yaml:"strategy,omitempty"`
 Setting  interface{}       `json:"setting,omitempty" yaml:"setting,omitempty"`
 Limit    float64           `json:"limit,omitempty" yaml:"limit,omitempty"`
}

type ThinkTime struct {
 Time float64 `json:"time" yaml:"time"`
}

1. ThinkTimeConfig 作为「思考时间」的整体策略，在 Config 中配置，参数说明如下：

• Strategy (支持如下四种策略)

  • default: 默认策略，会保持测试用例中设置的思考时间

  • random_percentage: 测试用例中设置的思考时间在指定放缩区间中随机选值

  • multiply: 对测试用例中设置的思考时间进行放缩

  • ignore: 忽略测试用例中设置的思考时间

• Setting (仅需random_percentage、multiply策略下配置，其他模式自动忽略此设置)

  • random_percentage：此策略下，需设置思考时间的最小最大放缩比：min_percentage、max_percentage（设置类型为map），默认: [0.5, 1.5]

  • multiply：此策略下，直接设置放缩比例（设置类型为float），默认: 1

• Limit

  • 对所有策略有效，如果设置且大于0，则限制最终的思考时间<=设定值，默认: -1(无限制)

2. ThinkTime 作为具体步骤间的「思考时间」配置，以单独的 step 存在，参数说明如下：

   • time: 不同测试步间的思考时间，单位为秒（second）

ThinkTime 使用示例:

config:
    name: 'h5 离线包下载'
    base_url: ${ENV(APP_LOGIN)}
    variables: {}
    think_time:  # 思考时间定义配置
        strategy: random_percentage  # 测试用例中设置的思考时间在指定放缩区间中随机选值
        setting:
           min_percentage: 1
           max_percentage: 1.5
         limit: 4
    exprot:
        - 'ticket'

teststeps:
 -   name: "APP login"
     api: har/login_app.yaml

 -   name: "离线包版本检查"
     api: har/checkH5OfflinePkgUpdate.yaml
     think_time:  # 定义思考时间
         time: 3  # 经过换算，测试步骤中的 think time 3 的最终值在 [3, 4]s 之间. 
         limit 4
     extract:
        h5_url: 'body.data.url'

 -    name: "离线包下载"
      api: har/h5OfflinePackageDownload.yaml

示例中，思考时间策略为随机比例（random_percentage），介于 100% ~ 150% 之间；limit 设置为 4s。经过换算，测试步骤中的 think_time 3 的最终值在 [3, 4]s 之间。

添加[集合点]

集合点可以确保指定的虚拟用户在同一时刻发起请求，实现类似「秒杀」的真实业务场景。

// 数据结构定义
type Rendezvous struct {
 Name           string  `json:"name" yaml:"name"`
 Percent        float32 `json:"percent,omitempty" yaml:"percent,omitempty"`
 Number         int64   `json:"number,omitempty" yaml:"number,omitempty"`
 Timeout        int64   `json:"timeout,omitempty" yaml:"timeout,omitempty"`
}

数据结构参数说明：

• name: 集合点名称，可定义为任意字符串

• percent: 触发集合点释放的虚拟用户百分比，范围为 (0, 1]，默认为 1，即全部用户

• number: 触发集合点释放的虚拟用户数量，范围为 (0, N]，N 为当前性能测试的所有并发用户数

• timeout: 虚拟用户到达集合点之间的间隔时间的最大值，单位为毫秒；当最近两个虚拟用户达到集合点的时间间隔大于最大值，则立即释放所有虚拟用户，如果没有指定，默认值为 5000 ms

集合点使用示例：

config:
 name: 'h5 离线包下载'
 base_url: ${ENV(APP_LOGIN)}
 variables: {}
 exprot:
 - 'ticket'

teststeps:
 - name: "APP login"
 api: har/login_app.yaml

 - name: "离线包版本检查"
 api: har/checkH5OfflinePkgUpdate.yaml
 extract:
 h5_url: 'body.data.url'

 - name: "离线包下载"
 api: har/h5OfflinePackageDownload.yaml
 rendezvous:  # 集合点
 name: '集合点'  # 设置集合点名称
 percent: 0.8  # 80% 虚拟用户
#        number: 100 # 100% 虚拟用户，percent/number 二选一
 timeout: 3000

针对「集合点」机制，有 2 个需要特别注意的点：

• number 和 percent 参数需要二选一并且保证合法；如果没有指定参数、同时指定了两个参数、或者参数不合法，则默认为需要全部虚拟用户到达集合点。

• 集合点仅在虚拟用户全部加载完之后的稳定阶段生效。

可以看出，HttpRunner v4.0 的「事务」「思考时间」「集合点」机制也跟 LoadRunner 保持了一致，功能特性和参数配置方法完全相同。

---

执行性能测试

准备好接口性能测试用例后，就可以开始使用 hrp boom 执行性能测试,通过命令行工具启动。

参数配置

当前 HttpRunner v4.0 支持多种性能测试策略，我们可以在命令行参数中进行指定。

关于性能测试的参数信息，可以通过 hrp boom -h 进行查看

$> hrp boom -h
run yaml/json testcase files for load test

Usage:
 hrp boom [flags]

Examples:
 $ hrp boom demo.json        # run specified json testcase file
 $ hrp boom demo.yaml        # run specified yaml testcase file
 $ hrp boom examples/        # run testcases in specified folder

Flags:
 --cpu-profile string              Enable CPU profiling.
 --cpu-profile-duration duration   CPU profile duration. (default 30s)
 --disable-compression             Disable compression
 --disable-console-output          Disable console output.
 --disable-keepalive               Disable keepalive
 -h, --help                            help for boom
 --loop-count int                  The specify running cycles for load testing (default -1)
 --max-rps int                     Max RPS that boomer can generate, disabled by default.
 --mem-profile string              Enable memory profiling.
 --mem-profile-duration duration   Memory profile duration. (default 30s)
 --prometheus-gateway string       Prometheus Pushgateway url.
 --request-increase-rate string    Request increase rate, disabled by default. (default "-1")
 --spawn-count int                 The number of users to spawn for load testing (default 1)
 --spawn-rate float                The rate for spawning users (default 1)

Global Flags:
 --log-json           set log to json format
 -l, --log-level string   set log level (default "INFO")

参数名称及功能直接复用 Locust/Boomer 的参数，虽然底层实现进行了比较大的改造，但用法基本保持了一致，感兴趣可以去查阅一下 Boomer 的参数文档。

设置并发用户数

性能测试需要指定并发用户数，需要按照阶梯加压的方式初始化并发用户。

• spawn-count：表示我们期望达到的最大并发用户数

• spawn-rate：表示达到期望最大并发前每秒增加的并发用户数

具体示例：

hrp boom testcase.yml --spawn-count 1000 --spawn-rate 100

在该示例中，指定了 1000 并发用户，按照每秒 100 个的速率初始化用户，预计在 10s 后可完成初始化。

注意：官方文档描述->在这种模式下，性能测试不会自动结束（除非指定循环次数或者压测时长）。当期望结束压测时，可以通过 kill 命令杀死进程，或者 Ctrl+C 来结束性能测试，结束时终端会打印整体测试数据。但是亲测会自动结束，当完成预期的并发用户时会立即结束。

设置 Ratelimiter

有时需要在性能测试时对发压流量进行限流，例如期望限制最大的 RPS，或者在初始化并发用户时限定增加速率。

• max-rps：限制 hrp 发压的最大 rps，默认不限制

• request-increase-rate：限制 hrp 每秒的请求增加速率，默认不开启，支持两种格式：“1”、“1/1s”

具体示例如下所示：

hrp boom testcase.yml --spawn-count 100 --spawn-rate 100 --max-rps 1000 --request-increase-rate 100

示例中，指定了 100 并发用户，按照每秒 100 个的速率初始化用户，预计在 1s 后可完成初始化。同时，我们限制在整个压测过程中，hrp 最高只能发压 1000 RPS，同时限定每秒增加的速率为 100 RPS。

设置循环次数

除了手动控制压测时长外，还支持按照指定的循环次数执行压测，可通过 --loop-count 参数进行指定。

需要说明的是， 执行循环次数的逻辑参考的是 JMeter，所有虚拟用户均会运行指定的循环次数，即当次压测的整体运行次数为：spawn-count * loop-count 执行如下命令，执行完指定循环次数后，HttpRunner 将结束运行并打印整体测试数据。

hrp boom test_ef_login.yaml --spawn-count 100 --spawn-rate 10 --loop-count 10

示例中，指定了 100 个并发用户，每个用户循序运行 1000 次，预计总共运行 100 * 10 = 1000次

---

指标数据分析

性能测试过程中，hrp 每隔 3s 会打印一次性能数据，其中汇总了 3s 内的所有请求情况。如果中途想关闭打印输出日志，可以在命令行中添加一个 --disable-console-output 参数

结果示例：

10:08AM WRN runner has stopped; skipping GoAttach
Current time: 2022/12/17 10:08:25, Users: 2, State: stopping, Total RPS: 18.5, Total Average Response Time: 794.3ms, Total Fail Ratio: 0.0%
Accumulated Transactions: 35 Passed, 0 Failed
+-------------+----------------+------------+---------+--------+---------+------+------+--------------+------------+-------------+
|    TYPE     |      NAME      | # REQUESTS | # FAILS | MEDIAN | AVERAGE | MIN  | MAX  | CONTENT SIZE | # REQS/SEC | # FAILS/SEC |
+-------------+----------------+------------+---------+--------+---------+------+------+--------------+------------+-------------+
| api         | APP login      |          1 |       0 |     84 |   84.00 |   84 |   84 |          917 |       0.33 |        0.00 |
| api         | 离线包版本检查 |          2 |       0 |     78 |   98.00 |   78 |  118 |          159 |       0.67 |        0.00 |
| api         | 离线包下载     |         28 |       0 |   2400 | 2447.46 | 1304 | 3647 |      5996374 |       9.33 |        0.00 |
| transaction | Action         |         28 |       0 |   2700 | 2816.32 | 1601 | 4048 |            0 |       9.33 |        0.00 |
+-------------+----------------+------------+---------+--------+---------+------+------+--------------+------------+-------------+

Current time: 2022/12/17 10:08:28, Users: 1, State: stopped, Total RPS: 17.1, Total Average Response Time: 829.9ms, Total Fail Ratio: 0.0%
Accumulated Transactions: 36 Passed, 0 Failed
+-------------+------------+------------+---------+--------+---------+------+------+--------------+------------+-------------+
|    TYPE     |    NAME    | # REQUESTS | # FAILS | MEDIAN | AVERAGE | MIN  | MAX  | CONTENT SIZE | # REQS/SEC | # FAILS/SEC |
+-------------+------------+------------+---------+--------+---------+------+------+--------------+------------+-------------+
| api         | 离线包下载 |          1 |       0 |   4600 | 4634.00 | 4634 | 4634 |      5996374 |       0.33 |        0.00 |
| transaction | Action     |          1 |       0 |   5000 | 4950.00 | 4950 | 4950 |            0 |       0.33 |        0.00 |
+-------------+------------+------------+---------+--------+---------+------+------+--------------+------------+-------------+

=========================================== Statistics Summary ==========================================
Current time: 2022/12/17 10:08:28, Users: 1, Duration: 6.314s, Accumulated Transactions: 36 Passed, 0 Failed
+-------+------------+---------+--------+---------+-----+------+--------------+------------+-------------+
| NAME  | # REQUESTS | # FAILS | MEDIAN | AVERAGE | MIN | MAX  | CONTENT SIZE | # REQS/SEC | # FAILS/SEC |
+-------+------------+---------+--------+---------+-----+------+--------------+------------+-------------+
| Total |        108 |       0 |    100 |  829.90 |  26 | 4634 |      1999150 |      17.10 |        0.00 |
+-------+------------+---------+--------+---------+-----+------+--------------+------------+-------------+

结果数据指标释义:

指标名称	指标说明
Users	当前虚拟用户数
State	的哪个区运行状态
Total RPS	RPS总数
Total Response	总响应时间
Total Fail Ratio	总请求错误率
Accumulated Transactions	事务总通过/失败数(含Action事务)
TYPE	请求类型
NAME	请求名称
REQUESTS	请求数
FAILS	请求失败数
MEDIAN	响应时间中间数
AVERAGE	响应时间平均值
MIN	响应时间最小值
MAX	响应时间最大值
CONTENT SIZE	响应内容大小
REQS/SEC	每秒请求数
FAILS/SEC	每秒请求失败数
Duration	测试持续时间

注意：表格内皆为统计间隔(3s)内的性能指标数据。完成性能测试时，会打印整体测试数据。Statistics Summary 展示的是性能测试整个过程中的总体指标数据

---

需求案例

为了便于理解，挑选了一个之前质量专项优化中的一个业务性能案例场景，但同时会尽量多地覆盖常用的性能测试特性(参考Jmeter/LoadRunner)。

需求案例描述：

[需求描述]对H5离线包下载优化相关接口进行压测，重点关注离线包下载接口并发下的成功率及性能情况.
[压测对象] : 用户登录/检查更新/离线包下载三个接口组成的业务场景
[ 事务 ]:业务层面重点关注 检查更新/离线包下载两个接口整体性能情况.
[思考时间]: 模拟真实用户实际操作过程,在用户登录和检查更新两个接口之间增加3s思考时间.
[集合点] :当虚拟用户数达到80%情况下进行释放
[ 预期目标 ] : 事务通过率100%，AVERAGE<3s，TPS>200

用例准备

config:
    name: 'h5 离线包下载'
    base_url: ${ENV(APP_LOGIN)}
    variables: {}
    think_time:  # 思考时间定义配置
      strategy: random_percentage  # 测试用例中设置的思考时间在指定放缩区间中随机选值
      setting:
        min_percentage: 1
        max_percentage: 1.5
      limit: 4
    exprot:
      - 'ticket'

teststeps:
    - name: "APP login"
      api: har/login_app.yaml

    - name: "离线包版本检查"
      api: har/checkH5OfflinePkgUpdate.yaml
      transaction:  # 定义事务
        name: 'transaction_check'  # 事务名称
        type: start  # 事务开始
      think_time:  # 定义思考时间
        time: 3  # 经过换算，测试步骤中的 think time 3 的最终值在 [3, 4]s 之间. limit 4
      extract:
        h5_url: 'body.data.url'

    - name: "离线包下载"
      api: har/h5OfflinePackageDownload.yaml
      transaction:
        name: 'transaction_check'
        type: end  # 事务结束
      rendezvous:  # 集合点
        name: '集合点'  # 设置集合点名称
        percent: 0.8  # 80% 虚拟用户
#        number: 100 # 100% 虚拟用户，percent/number 二选一
        timeout: 3000

执行性能测试

由于环境数据受限，测试数据只准备了1个用户，实际压测结果稍微会有些偏差，不影响整体性能演示。

$ hrp boom test_downloadOfflinePackages_h5.yaml --spawn-count 100 --spawn-rate 10  -- loop-count 10

Current time: 2022/12/17 11:17:29, Users: 14, State: stopping, Total RPS: 16.1, Total Average Response Time: 647.9ms, Total Fail Ratio: 0.0%
Accumulated Transactions: 23 Passed, 0 Failed
+-------------+----------------+------------+---------+--------+---------+------+------+--------------+------------+-------------+
|    TYPE     |      NAME      | # REQUESTS | # FAILS | MEDIAN | AVERAGE | MIN  | MAX  | CONTENT SIZE | # REQS/SEC | # FAILS/SEC |
+-------------+----------------+------------+---------+--------+---------+------+------+--------------+------------+-------------+
| api         | APP login      |          2 |       0 |     70 |   82.00 |   70 |   94 |          917 |       0.67 |        0.00 |
| api         | 离线包版本检查 |          4 |       0 |     83 |   95.50 |   63 |  153 |          159 |       1.33 |        0.00 |
| api         | 离线包下载     |         16 |       0 |   2700 | 2678.56 | 1837 | 3958 |      5996374 |       5.33 |        0.00 |
| transaction | Action         |         16 |       0 |   3000 | 3027.62 | 2139 | 4216 |            0 |       5.33 |        0.00 |
+-------------+----------------+------------+---------+--------+---------+------+------+--------------+------------+-------------+

Current time: 2022/12/17 11:17:32, Users: 1, State: stopped, Total RPS: 15.5, Total Average Response Time: 1045.8ms, Total Fail Ratio: 0.0%
Accumulated Transactions: 36 Passed, 0 Failed
+-------------+------------+------------+---------+--------+---------+------+------+--------------+------------+-------------+
|    TYPE     |    NAME    | # REQUESTS | # FAILS | MEDIAN | AVERAGE | MIN  | MAX  | CONTENT SIZE | # REQS/SEC | # FAILS/SEC |
+-------------+------------+------------+---------+--------+---------+------+------+--------------+------------+-------------+
| api         | 离线包下载 |         13 |       0 |   3800 | 3953.38 | 2905 | 6384 |      5996374 |       4.33 |        0.00 |
| transaction | Action     |         13 |       0 |   4200 | 4288.31 | 3281 | 6572 |            0 |       4.33 |        0.00 |
+-------------+------------+------------+---------+--------+---------+------+------+--------------+------------+-------------+

=========================================== Statistics Summary ==========================================
Current time: 2022/12/17 11:17:32, Users: 1, Duration: 6.974s, Accumulated Transactions: 36 Passed, 0 Failed
+-------+------------+---------+--------+---------+-----+------+--------------+------------+-------------+
| NAME  | # REQUESTS | # FAILS | MEDIAN | AVERAGE | MIN | MAX  | CONTENT SIZE | # REQS/SEC | # FAILS/SEC |
+-------+------------+---------+--------+---------+-----+------+--------------+------------+-------------+
| Total |        108 |       0 |    110 | 1045.79 |  23 | 6384 |      1999150 |      15.49 |        0.00 |
+-------+------------+---------+--------+---------+-----+------+--------------+------------+-------------+

2022-12-17T11:17:34.767+0800 [WARN]  grpc-py: plugin failed to exit gracefully

从以上性能测试结果来看，与预期存在一定差异。需要对下载接口进行进一步优化。

性能监控(实时)

除了在终端中查看性能测试过程和结果汇总数据之外，还可以通过配置 Prometheus + Grafana 看板，实现 Web 化的实时监控指标展示。

img

关于 Prometheus + Grafana 的性能监控配置方面的内容下次再进行分享。敬请期待......

如果还想了解关于多机负载(Master->Worker)的性能测试可以查阅官网：多机负载