【Jmeter】项目压测流程
- 【一】压测前准备
- 【二】常用压测工具
-
- 【1】JMeter（Java，企业最常用）
- [【2】k6（Go 写，轻量，现在越来越流行）](#【2】k6（Go 写，轻量，现在越来越流行）)
- [【3】ab(Apache Bench)](#【3】ab(Apache Bench))
- 【三】压测指标
- [【四】SpringBoot 常见压测瓶颈点](#【四】SpringBoot 常见压测瓶颈点)
- 【五】压测执行步骤流程
- 【六】简单压测报告模板示例
压测目的：找出系统吞吐量、响应时间、瓶颈点、最大并发、崩溃阈值，评估系统能不能扛住线上流量。
【一】压测前准备
【1】环境隔离
✅ 压测环境和线上环境配置尽量一致：CPU、内存、JVM 参数、数据库、中间件配置。
❌ 禁止直接在生产环境压测，会打垮业务。
【2】监控必须全套开启（没有监控的压测等于白跑）
（1）JVM 监控：Prometheus+Grafana / SpringBoot Actuator + Micrometer
指标：CPU 使用率、堆内存、非堆 (元空间)、GC 次数、GC 停顿时间、线程数、活跃线程、阻塞线程
（2）系统监控：服务器 CPU、内存、磁盘 IO、网络带宽、load 平均负载
（3）中间件监控
MySQL：QPS、TPS、慢 SQL、连接数、锁等待、Buffer Pool 命中率
Redis：ops、内存、连接数、网络
连接池：Hikari 活跃连接、等待队列、最大连接数
（4）业务接口指标：QPS (TPS)、平均响应时间 P50/P95/P99、错误率
【3】压测接口准备
（1）选择核心接口：查询接口、提交接口，尽量覆盖真实业务场景；不要只压简单 hello 接口。
（2）接口参数尽量模拟真实入参；有鉴权要带上 token；如果是动态数据源接口，要准备好测试数据源。
（3）关闭无关日志：压测环境把 info→warn，关闭大量 debug 日志，日志会严重影响性能。
（4）JVM 参数调到位，和生产对齐
bash
-Xms4g -Xmx4g -XX:+UseG1GC【4】压测之前确认
数据库数据量尽量贴近线上（千万 / 百万级别，不要空库压测）；
预热：刚启动 JVM 有 JIT 编译，压测前先跑几分钟预热，再统计指标，否则结果偏低。
【二】常用压测工具
【1】JMeter（Java，企业最常用）
GUI 只用来编写脚本，压测必须使用命令行非 GUI 模式运行，GUI 本身消耗性能。
bash
jmeter -n -t test.jmx -l result.jtl -e -o report优点：支持 http、jdbc、dubbo，参数化、断言、集合点，生成 HTML 报告。
缺点：压测机本身是 Java 程序，并发太高压测机会先 CPU 打满，大并发需要分布式压测。
【2】k6（Go 写，轻量，现在越来越流行）
脚本 JavaScript，压测机性能很高，单机可以模拟上万并发。
【3】ab(Apache Bench)
简单快速，适合简单接口，不适合复杂业务。
bash
ab -n 10000 -c 100 http://127.0.0.1:8080/xxx注意：压测机与被测服务分开，不要在同一台机器压自己，否则服务器资源被压测工具占用，数据不准。
【三】压测指标
核心四大指标：TPS/QPS、响应时间 RT、错误率、并发数
⚠️不要只看平均响应时间！平均会掩盖慢请求，重点看 P95、P99 分位值。
【1】压测两个关键场景
（1）基准压测：少量并发，看接口正常性能基线。
（2）梯度加压压测：逐步增加并发，观察 QPS 什么时候不再上涨、RT 飙升、错误率上升。
QPS 不再上升的拐点，就是系统最大吞吐量；
一旦错误率 > 0，停止加压，此时已经过载。
【2】压测通过标准（通用业务标准，可按产品需求调整）
（1）在目标业务 QPS 下：
错误率 = 0%
P95 响应时间 ≤500ms，P99 ≤1000ms
应用服务器 CPU ≤75%，无频繁 Full GC
MySQL CPU ≤70%，无大量慢 SQL，数据库连接池不耗尽
（2）稳定性压测（长稳）：在目标 QPS 下持续跑 30 分钟～2 小时
内存不能持续上涨，不能内存泄漏；GC 正常；连接数不泄露；
不能出现连接泄漏、线程泄漏、文件句柄耗尽。
很多系统短时压测很好，跑半小时后内存慢慢涨爆，长稳压测就是用来发现泄漏。
扩容预留：压测出系统最大稳定 QPS 后，线上容量规划一般预留 1.5‑2 倍余量，应对流量突增。
【四】SpringBoot 常见压测瓶颈点
（1）数据库瓶颈（最常见）
慢 SQL、缺少索引；MySQL CPU 打满；
Hikari 连接池配置过小，大量请求排队等待数据库连接；
（2）JVM 问题：内存泄漏、频繁 GC、元空间溢出
（3）Tomcat 容器线程数不足：server.tomcat.threads.max默认 200，高并发下线程耗尽
yml
server:
tomcat:
threads:
max: 400（4）同步阻塞代码，锁竞争，大量线程 WAIT/BLOCKED
（5）日志打印过多，磁盘 IO 打满
（6）Redis/Others 中间件响应慢成为下游瓶颈
（7）之前我们写的动态数据源场景：动态加载驱动、连接池创建逻辑，要重点压，看有没有类加载、连接泄漏。
如何定位瓶颈
CPU 高：top → jstack抓线程堆栈，看哪些线程耗 CPU；
内存上涨、GC 频繁：jmap dump 堆快照 MAT 分析；
接口 RT 很高，CPU 不高：多半 IO 瓶颈（数据库、网络）；
线程数暴涨：线程池耗尽、数据库连接耗尽。
【五】压测执行步骤流程
（1）梳理业务，确定业务预期 QPS、并发、SLA 响应时间指标；
（2）准备压测环境，部署应用，全套监控；JVM 参数与生产对齐；
（3）编写压测脚本，参数化，预热 JVM；
（4）基准测试，低并发跑一遍，拿到基线；
（5）梯度加压：逐步加大并发，记录每一档 QPS、P95/P99、CPU、错误率，直到出现错误或者 RT 大幅恶化；
（6）稳定性压测：取 80% 最大稳定 QPS，持续长时间运行，观察内存泄漏、资源泄漏；
（7）记录报告：压测环境配置、JVM 参数、并发、QPS、RT (P50/P95/P99)、CPU、GC、数据库指标，系统瓶颈点，优化建议。
（8）优化后重新压测对比。
【六】简单压测报告模板示例
业务接口：动态数据源查询接口
环境配置：4C8G，JVM Xmx4G
目标指标：QPS≥200，P95<500ms，错误率 0
压测结果：
并发 100 线程：QPS=320，P95=380ms，P99=720ms，CPU62%，错误率 0 ✔满足
并发 200 线程：QPS=380，P95=850ms，数据库 CPU 达到 78%，RT 开始上涨，到达瓶颈
长稳 1 小时：内存无持续上涨，无 Full GC。
瓶颈：MySQL 查询，建议增加索引优化 SQL。