Jmeter压测实操指南
一、性能指标
基础性能指标
响应时间（Response Time, RT）
用户发起请求到接收响应所需的总时间，包括网络传输、服务器处理等。关键分位点：TP90/TP95/TP99（如TP99表示99%请求的响应时间低于该值）。
TPS（Transactions Per Second，每秒事务数）
服务器每秒完成的事务处理数量，吞吐量直接体现了软件系统的业务处理能力。
并发用户数（Concurrency）
在特定时间范围内同时访问系统的用户数量；严格来说，表示同时请求同一接口的客户端数，直接影响系统处理压力的能力。
资源利用率指标
硬件资源
- CPU使用率：反映计算资源负载，持续＞80%可能需优化代码或扩容。
- 内存占用：包括RAM使用量和交换分区（Swap）情况。
软件资源
数据库连接池使用率、线程池活跃线程数等。
稳定性与可靠性指标
错误率（Error Rate）
失败请求占总请求的比例，计算公式：
错误率 = (失败事务数 / 总事务数) × 100%。高错误率可能提示系统瓶颈或代码缺陷。
饱和度（Saturation）
系统资源的最短板利用率（如CPU、内存、I/O），接近100%时性能急剧下降。
扩展性指标
水平扩展能力
通过增加节点提升吞吐量的线性程度，如吞吐量提升比例 / 节点增加比例。
弹性伸缩响应时间
弹性扩容/缩容触发到资源就绪的延迟。
二、典型测试场景以及Ramp-Up时间设置建议
系统基准测试
特点：快速评估系统基础性能
建议：5-30 秒的短 Ramp-Up
示例：100 用户，20 秒内线性增加
容量规划测试
特点：寻找系统性能拐点
建议：数分钟至小时的缓慢加压
示例：1000 用户，10 分钟内逐步增加
峰值压力测试
特点：模拟突发高并发
建议：1-5 秒的极短 Ramp-Up
示例：模拟秒杀场景，500 用户瞬间启动
稳定性测试
特点：长时间运行观察系统表现
建议：1-5 分钟的中等 Ramp-Up
示例：持续 8 小时测试，用户缓慢加压
三、几种并发线程组
原生线程组
- 线程数：相当于模拟用户的数量，假如设置为10可以理解为10个虚拟用户
- Ramp-Up时间（秒）：达到指定线程数需要的时间，例如线程数为10，时间设定为10s，那么就是10s加载完成10个线程，每秒启动的线程数为10/10=1
- 循环次数：不勾选永远则按照所输入的值循环执行线程组下的请求；勾选永远则会一直执行，勾选永远后一般会勾选调度器来设置运行的持续时间。
- 启动延迟（秒）：测试计划延迟启动时间。
Concurrency Thread Group(递增式并发线程组)
这个用来模仿递增式并发，并可设置递增次数、递增时长、到达目标递增数量保持时长等等
- Target Concurrency：目标并发（总线程数）
- Ramp Up Time：加速时间（总加速时长）
- Ramp-Up Steps Count：加速步骤计数（总加速/递增次数）
- Hold Target Rate Time：保持目标速率时间（到达总线程数后持续时长）
- Time Unit：时间单位（分钟或者秒）
- Thread Iterations Limit：线程迭代次数限制（循环次数）
- Log Threads Status into File：将线程状态记录到文件中（将线程启动和线程停止事件保存为日志文件）
根据上面字段含义，图上设置跟曲线图应该比较好理解：
设置50并发，按5线程/sec在10s内启动完所有线程，持续120sec
Stepping Thread Group(逐步线程组)
用来模仿递增式并发(递增和递减都可以)，并可设置递增次数、递增启动延迟、递增时长、到达目标递增数量保持时长
其中各字段含义如下：
·This group will start:线程组最大用户数
·First, wait for:初次加载用户前等待时间
·Then start:第一次加载用户数
·Next, add - threads every - using ramp-up:然后增加用户每隔几秒，在几秒内启动线程组
·Then hold load for：运行持续时间
·Finally, stop - threads every：停止线程数，间隔每几秒
Ultimate Thread Group（最终线程组）
由多个线程组设置的结合。执行的时候，每个线程组是同时按照自己的规则开始执行的，每一时刻，得到的结果都是两个线程组的叠加
其中各字段含义如下：
·Start Threads Count：启动多少线程
· Initial Delay, sec：延迟多少秒开始启动线程
· Startup Time, sec：启用{Start Threads Count} 个线程花费多少秒
· Hold Load For, sec：线程全部启动完成后再持续运行多少秒，在此期间，每个线程请求完一遍后会再次发起相同的请求，若有思考时间，则会间隔设定的思考时间后再发起
· Shutdown Time：在多少秒内将 {Start Threads Count} 个线程全部停掉
四、API接口压测实操
测试接口：/v1/opp/get-opp-by-id
压测环境：生产**
性能目标：
- 所有接口响应时间在 1s（1000ms）以内
- 事务错误率控制在 0.3%以下
- TPS稳定性
- 200并发，cpu使用率<40%,内存<30%，数据库处理正常
10并发：
15并发：
20并发
结论：
10-15-20并发时，QPS呈上升趋势，最后稳定在220左右，此时所有接口响应时间均<1s,错误率为0，内存使用率19%，但CPU使用率已经>100%;CPU成为目前明显瓶颈；
可能的原因
CPU密集型计算任务
复杂算法、序列化/反序列化操作可能导致CPU负载过高。
线程上下文切换开销过大
频繁的线程切换会消耗CPU资源，降低整体吞吐量。
同步阻塞操作导致CPU空转
线程因同步锁或I/O阻塞而等待，造成CPU资源浪费。
优化方案
代码层面优化
- 减少CPU密集型操作，优化算法复杂度，避免嵌套循环。
- 使用更高效的序列化方案（如Protobuf替代JSON）。
- 异步化改造，避免同步阻塞。
基础设施优化
- 监控CPU使用率，必要时扩容。
- 使用APM工具（如Arthas、SkyWalking）定位热点方法。
- 升级更高主频的CPU或增加核心数。
缓存优化
- 对计算结果进行缓存（Guava/Redis）。
- 采用多级缓存策略，减少重复计算。