第二章. 第一次亲密接触：压测你的 Spring Boot 接口

第二章. 第一次亲密接触：压测你的 Spring Boot 接口

摘要：本章我们将正式启动 JMeter，编写第一个测试脚本。我们将深入理解 JMeter 的 “核心三剑客”（线程组、取样器、监听器），并对上一章编写的 Spring Boot 接口发起真实的并发调用，最后通过聚合报告学会看懂基本的性能数据。

本章学习路径

我们将通过以下步骤完成第一次压测实战：

  • 2.1 JMeter 核心逻辑架构
    • 2.1.1 核心三剑客：测试计划的骨架
    • 2.1.2 线程组与并发用户的映射关系
  • 2.2 编写第一个压测脚本
    • 2.2.1 配置线程组（模拟用户）
    • 2.2.2 配置 HTTP 请求（发起攻击）
    • 2.2.3 添加结果树（查看明细）
  • 2.3 运行与数据解读
    • 2.3.1 成功与失败的标志
    • 2.3.2 聚合报告核心指标解读
    • 2.3.3 GUI 模式的性能陷阱

2.1. JMeter 核心逻辑架构

在上一章中，我们已经准备好了基于 com.demo.jmeterdemo 包结构的 Spring Boot 项目。现在打开 JMeter，面对空空如也的界面，我们需要先理解它的构建逻辑。

JMeter 的脚本编写其实就是在 “搭积木”，而最核心的三块积木被称为 “三剑客”。

2.1.1. 核心三剑客

组件名称英文名称对应现实场景作用
线程组Thread Group用户决定有多少人来访问，以及这些人进来的速度（并发数）。
取样器Sampler动作决定用户做什么操作（打开网页、调用接口、查询数据库）。
监听器Listener报表负责收集测试结果，展示为图表、表格或日志。

2.1.2. 线程组 = 虚拟用户

在 Java 开发中，我们知道 “线程（Thread）” 是 CPU 调度的基本单位。在 JMeter 中，一个线程就严格对应一个虚拟用户。

  • 如果设置 10 个线程，就意味着有 10 个用户同时在这个时间点操作。
  • 这与 Spring Boot 中的 Tomcat 线程池是对应的：客户端发起 10 个线程请求，服务端就需要分配资源来处理这 10 个请求。

2.2. 编写第一个压测脚本

理论清楚后，我们开始动手。请确保你的 Spring Boot 项目（JmeterDemoApplication）已启动，且端口为 8080。

2.2.1. 第一步：创建线程组（模拟用户）

操作步骤：

  1. 右键点击 “测试计划 (Test Plan)” -> 添加 (Add) -> 线程 (Threads) -> 线程组 (Thread Group)。

image-20251119092909690

  1. 在右侧面板配置以下参数：
参数名建议值含义解释
名称模拟前台用户给脚本起个可读的名字，便于管理。
线程数 (Number of Threads)10模拟 10 个用户并发访问。
Ramp-Up 时间 (Ramp-Up Period)1让这 10 个用户在 1 秒内陆续启动（即每 0.1 秒启动一个），避免瞬间压力过大导致系统误判。
循环次数 (Loop Count)10每个用户执行 10 次操作。总请求数 = $10 \times 10 = 100$。

关于 Ramp-Up 的思考：如果设置线程数为 100，Ramp-Up 为 0，意味着 100 人在同一毫秒瞬间涌入（秒杀场景）。如果设置线程数为 100，Ramp-Up 为 10，意味着每秒进来 10 人（常规业务场景）。

2.2.2. 第二步：配置 HTTP 请求（定义动作）

我们要调用的接口地址是：GET http://localhost:8080/api/test/hello

操作步骤：

  1. 右键点击刚才创建的 “线程组” -> 添加 -> 取样器 (Sampler) -> HTTP 请求 (HTTP Request)。

image-20251119093442038

  1. 填写核心配置：
    • 协议 (Protocol)：http
    • 服务器名称或 IP：localhost
    • 端口号：8080
    • 方法 (Method)：GET
    • 路径 (Path)：/api/test/hello (注意不要包含 host 和 port，且以 / 开头)

2.2.3. 第三步：添加监听器（查看结果）

为了验证脚本是否配置正确，我们需要一个能够看到详细请求响应的组件。

操作步骤：

  1. 右键点击 “线程组” -> 添加 -> 监听器 (Listener) -> 察看结果树 (View Results Tree)，这样就够了

2.3. 运行与数据解读

脚本编写完成，点击工具栏上的绿色 启动按钮 (Start)。记得先保存脚本，通常命名为 hello-test.jmx。

2.3.1. 察看结果树：调试神器

运行结束后，点击左侧的 “察看结果树”。你会在列表中看到 100 条记录（10 线程 x 10 循环）。

  • 绿色盾牌：表示请求成功（HTTP 状态码 200）。
  • 红色感叹号：表示请求失败。

点击任意一条成功的记录，切换到 响应数据 (Response Data) 选项卡：

1
2
3
4
5
6
{
    "code": 200,
    "message": "success",
    "data": "Processing time: 85ms",
    "timestamp": 1731980000123
}

image-20251119093724251

如果你看到了我们在 Spring Boot 代码中定义的 JSON 返回，说明 网络连通性 和 接口逻辑 都没有问题。

2.3.2. 聚合报告：宏观视角

“察看结果树” 只能看单次请求的细节，无法评估整体性能。我们需要添加 “聚合报告” 来查看 TPS 和 RT。

操作步骤：

  1. 右键点击 “线程组” -> 添加 -> 监听器 -> 聚合报告 (Aggregate Report)。
  2. 清除数据：点击工具栏的小扫把（清除全部），然后重新运行一次测试。

核心指标解读：

image-20251119093834565

指标 (Label)含义理想状态
样本 (Samples)总请求数应等于 线程数 x 循环次数。
平均值 (Average)平均响应时间 (ms)越低越好。但在长尾效应下，参考价值不如 99% 线。
99% 百分位 (99% Line)最重要的指标表示 99% 的请求都在这个时间内完成了。这代表了绝大多数用户的体验。
异常 % (Error %)错误率必须为 0.00%。任何报错都需要排查。
吞吐量 (Throughput)TPS每秒处理请求数。越高越好（前提是报错率为 0）。

实战分析：假设你的聚合报告显示：

  • Average: 75ms
  • Throughput: 120.5/sec

这说明在当前并发下，我们的 Spring Boot 应用每秒能处理约 120 个请求，平均每个请求处理耗时 75ms（这与我们在代码中写的 Thread.sleep(50~100) 吻合）。

2.3.3. 重要警告：GUI 模式的陷阱

新手必读：在使用 JMeter 进行 正式的大规模压测（例如成千上万并发）时，严禁 开启 “察看结果树” 和 “聚合报告” 等 GUI 监听器。

因为 GUI 组件渲染图表和记录实时日志会消耗大量的客户端 CPU 和内存资源。这会导致 JMeter 自身成为瓶颈，测量出的数据不准确（比如 TPS 上不去是因为你电脑卡了，而不是服务器卡了）。

最佳实践：

  • GUI 模式：仅用于编写、调试脚本（验证通不通）。
  • CLI (命令行) 模式：用于正式执行压测（验证快不快）。我们将在后续章节详细讲解。

2.4. 本章小结

在本章中，我们打通了 JMeter 到 Spring Boot 的第一条测试链路。

核心要点：

  1. 三剑客：线程组（人）、取样器（动作）、监听器（结果）是构建脚本的基石。
  2. Ramp-Up：用于控制用户进入系统的速率，避免瞬间洪峰导致测试失真。
  3. 指标分析：重点关注 99% Line（绝大多数人的体验）和 Throughput（系统处理能力），而不是简单的平均值。
  4. GUI 限制：调试用 GUI，压测用 CLI。

下一步计划：目前的脚本虽然能跑，但所有参数都是 “写死” 的。在真实业务中，每个用户的 ID、Token 或者查询的商品都不一样。在下一章，我们将学习 变量与参数化，让我们的压测脚本学会 “千人千面”。