JMeter 是 Apache 的压力测试工具——模拟大量用户并发请求，测系统的承载上限和性能瓶颈。这篇快速入门：核心概念、怎么跑压测、怎么看结果。
一、解决什么问题：系统能扛多少并发
单机跑没问题 ≠ 上线能扛。压测回答三个问题：
- QPS：每秒能处理多少请求（吞吐量）
- 响应时间：一个请求平均/最慢多久返回
- 瓶颈在哪：CPU？数据库？还是接口本身慢
二、核心概念
| 概念 | 是什么 |
|---|---|
| 线程组 | 模拟并发用户（线程数 = 并发数） |
| HTTP 请求 | 压测的目标接口（URL、方法、参数） |
| 监听器 | 看结果（汇总报告、聚合报告） |
| QPS | 每秒请求数（吞吐量） |
| TP99 | 99% 的请求在多少毫秒内完成（长尾指标） |
补充：TP99 的 TP 是什么
TP = Top Percentile（百分位），也叫尾部百分位。TP99 的意思是：把一段时间内所有请求的耗时从短到长排序，第 99% 位置的耗时就是 TP99——也就是 99% 的请求都比它快，只有最慢的 1% 超过它。
| 指标 | 含义 | 看什么 |
|---|---|---|
| TP50 / P50 | 一半请求的耗时（中位数） | 大多数用户的体感 |
| TP99 | 99% 请求的耗时上限 | 最差那 1% 用户的体感 |
| TP999 | 99.9% 请求的耗时上限 | 极端慢请求 |
为什么看 TP99 而不是平均值：平均值会被几个超慢请求拉高，掩盖"大多数请求其实很快"；TP99 直接反映尾部延迟——而尾部慢恰恰是用户能感知的（比如偶尔卡一下）。压测报告里平均值再好看，TP99 涨了就是有问题。
判断标准：
- QPS 高 + TP99 低 = 性能好：吞吐大、响应稳定，系统健康
- QPS 上不去 + TP99 飙升 = 有瓶颈：请求全在排队等某个资源，三个最常见瓶颈：
- 数据库连接池耗尽——请求排队等连接，连接池被占满
- 慢 SQL——数据库成了瓶颈，一个慢查询拖慢所有依赖它的请求
- 锁竞争——线程在互斥等待（同步块、分布式锁），并发越高越慢
排查顺序也按这个来：先看 TP99 是否在涨、QPS 是否卡住，再看连接池/SQL/锁。
三、跑一个压测
GUI 方式（学习和调试）：
1. 新建线程组：线程数 100、Ramp-Up 10 秒（100 个用户 10 秒内陆续启动）
2. 线程组下加「HTTP 请求」：填 URL、方法（GET/POST）、参数
3. 加「汇总报告」监听器
4. 点运行，看结果CLI 方式（正式压测，无头跑）：
bash
# 测试计划保存为 load_test.jmx 后
jmeter -n -t load_test.jmx -l result.jtl -e -o report/
# -n 无头模式 -l 原始结果 -e -o 生成 HTML 报告四、看结果
「汇总报告」关键列：
| 列 | 含义 |
|---|---|
| Samples | 总请求数 |
| Average | 平均响应时间（ms） |
| Error % | 错误率（>0 要查） |
| Throughput | 吞吐量（QPS） |
加压方法：线程数从 10 → 50 → 100 → 500 逐步加，看 QPS 在哪开始不涨（瓶颈点）——这就是系统的"承载上限"。
小结
- JMeter 用线程组模拟并发，测 QPS 和响应时间
- 核心指标：QPS（吞吐）、TP99（长尾）、错误率
- 逐步加压找瓶颈点：QPS 不涨 = 到顶了
- 正式压测用 CLI（
-n -t -l -e -o），GUI 只做调试
想了解瓶颈怎么定位（数据库/接口/代码），看《线上调试快速入门》；想看一次完整压测的实战过程（场景设计、数据分析、瓶颈定位），看《一次真实的服务器压测实战》。