压力测试基础回顾：核心概念与关键指标
在深入异常波动根因分析之前，必须夯实压力测试的基础认知。本章将厘清压力测试与负载测试的本质区别，解析四大关键性能指标，并对比主流压测工具的选型策略。
一、压力测试 vs 负载测试：目标与场景的差异
很多工程师将两者混为一谈，但它们在测试目标、施压方式和结果解读上存在根本性差异。
| 维度 | 负载测试 (Load Testing) | 压力测试 (Stress Testing) |
|---|---|---|
| 核心目标 | 验证系统在预期正常负载下的性能表现 | 找出系统的极限承受能力和崩溃点 |
| 施压方式 | 逐步增加并发到目标值，保持稳定 | 持续增加并发直至系统过载或崩溃 |
| 关注重点 | 响应时间、吞吐量是否满足SLA | 系统何时降级、如何恢复、数据一致性 |
| 典型场景 | 日常业务峰值、促销活动预估 | 突发流量、DDoS模拟、雪崩测试 |
| 结果解读 | 是否达标 → 优化或扩容 | 极限值 → 熔断/限流/降级策略验证 |
实战建议：在根因分析课程中，我们主要使用压力测试来触发异常波动。因为只有让系统逼近极限，隐藏的瓶颈（如连接池耗尽、GC风暴、死锁）才会暴露。
二、四大关键性能指标（TPS、RT、Error Rate、资源利用率）
指标是压测的“仪表盘”。任何异常波动最终都会体现在这四个维度的联动变化上。
- TPS (Transactions Per Second)：每秒完成的事务数，代表系统的吞吐能力。异常波动时，TPS可能出现“断崖式下跌”或“锯齿状抖动”。
- RT (Response Time)：从请求发出到收到完整响应的耗时。通常关注P99、P95、Avg。RT突然飙升往往是系统进入瓶颈区的第一信号。
- Error Rate：错误请求占总请求的比例。包括HTTP 5xx、超时、连接拒绝等。压测中Error Rate不应超过1%，异常波动时可能瞬间飙升至10%以上。
- 资源利用率：CPU、内存、磁盘I/O、网络带宽的使用百分比。资源利用率达到100%并不一定代表异常，但若在TPS下降时资源利用率反而升高，则说明系统正在做“无用功”（如自旋、重试、GC）。
根因分析黄金法则：不要孤立看单一指标。例如“RT升高+TPS下降+CPU 100%”通常指向计算瓶颈；“RT升高+TPS下降+CPU 30%”则可能指向锁竞争或IO等待。
三、测试环境与工具选型
环境隔离和工具选择直接影响压测结果的可靠性。以下是三种主流工具的对比与选型建议。
| 工具 | 协议支持 | 脚本语言 | 分布式能力 | 适用场景 |
|---|---|---|---|---|
| JMeter | HTTP/HTTPS、JDBC、JMS、gRPC等 | GUI配置 + Groovy/Java | 原生支持（主从模式） | 企业级全协议压测、复杂业务链路 |
| Locust | HTTP/HTTPS（可扩展自定义协议） | Python | 原生支持（Master-Worker） | 快速原型、Python技术栈团队、动态场景 |
| wrk | HTTP/HTTPS | Lua脚本 | 单机多线程（无原生分布式） | 高并发基准测试、快速验证单机极限 |
选型避坑：不要用wrk做复杂业务链路压测（如登录→下单→支付），它只适合单接口基准测试。JMeter和Locust都支持分布式，但JMeter的分布式同步和资源消耗更大，Locust的Python协程模型在IO密集型场景下更轻量。
四、压测工具核心架构对比（SVG）
下图展示了JMeter与Locust在分布式压测中的架构差异，理解这些差异有助于在异常波动时快速定位是工具瓶颈还是系统瓶颈。
五、压测脚本快速上手示例
以下提供三种工具的压测脚本片段，用于快速启动一个HTTP GET接口的压测任务。
JMeter (通过命令行执行，非GUI模式)
# 创建测试计划 test.jmx 后，使用以下命令执行
jmeter -n -t test.jmx -l result.jtl -e -o report/
# -n: 非GUI模式 -t: 测试计划文件 -l: 结果文件 -e: 生成报告 -o: 报告输出目录Locust (Python脚本)
# locustfile.py
from locust import HttpUser, task, between
class WebsiteUser(HttpUser):
wait_time = between(1, 3) # 用户等待时间1-3秒
@task
def index_page(self):
self.client.get("/api/health")wrk (Lua脚本 + 命令行)
# 直接命令行压测（无Lua）
wrk -t12 -c400 -d30s http://target.com/api/health
# -t: 线程数 -c: 连接数 -d: 持续时间
# 使用Lua脚本自定义请求
wrk -t4 -c200 -d60s -s custom.lua http://target.com/api/health
实战提示：在压测过程中，务必同时监控压测工具所在机器的资源（CPU、内存、网络）。如果压测工具自身资源耗尽，压测结果将无法反映被测系统的真实性能。建议使用独立的压测机或容器化部署。
六、压测执行流程与关键检查点（SVG）
一个标准化的压测执行流程能大幅减少因操作失误导致的异常波动误判。下图展示了从准备到分析的完整步骤。
本章小结：压力测试与负载测试的目标不同，但都需要关注TPS、RT、Error Rate和资源利用率这四个核心指标的联动变化。JMeter、Locust、wrk各有适用场景，选型时应考虑协议支持、脚本语言和分布式能力。标准化的压测执行流程（预热→基线→阶梯加压→持续压测→分析）是避免误判的基础。下一章将正式进入异常波动的根因分析方法论。