JMeter 压测结果实操演算：QPS、TPS 完整计算案例

JMeter 压测结果实操演算：QPS、TPS 完整计算案例

前置场景设定

电商下单完整业务链路：

 

登录→获取商品→提交订单→扣库存→支付

 

整套事务一共调用 6 个接口

 

压测配置：

 

虚拟用户数（并发线程数）：200 线程

 

压测持续时长：300 秒（5 分钟）

 

压测结束后 JMeter 聚合报告最终数据：

1. 所有请求总次数：240000 次（全部接口累加）
2. 完整下单事务总次数：40000 次
3. 平均响应时间 (RT)：200ms = 0.2s
4. 思考时间：0（纯压测无停顿）

一、分步计算

1. 计算 QPS（每秒请求数）

公式：

\(QPS = 总请求数 ÷ 压测总时长\)

 

QPS = 240000 ÷ 300 = 800

 

含义：系统每秒处理 800 次接口请求

2. 计算 TPS（每秒事务数）

公式：

\(TPS = 总事务数 ÷ 压测总时长\)

 

TPS = 40000 ÷ 300 ≈ 133.33

 

含义：每秒完成 133.33 笔完整下单订单

3. 互相校验换算

一笔事务调用 6 个接口

 

理论：\(QPS = TPS × 6\)

 

133.33 × 6 ≈ 800，和上面 QPS 完全对上，数据无误。

二、经典性能公式反向验算

公式：\(TPS = 并发数 ÷ 平均响应时间(秒)\)

 

并发 = 200，RT=0.2s

 

TPS = 200 / 0.2 = 100

 

⚠️ 这里出现差值：

 

理论计算 100，实际压测 133.33

 

原因：

 

公式是理想无阻塞、无资源争抢的理论值；

 

真实服务器多核并行处理请求，调度效率更高，实际 TPS 会高于纯理论估算值。

三、加上思考时间（模拟真实用户）

如果用户每操作完停顿 1 秒（思考时间 Think Time=1s）

 

公式：

 

\(TPS = 并发数 ÷ (RT + 思考时间)\)

 

TPS = 200 ÷ (0.2+1) ≈ 166.67

 

思考时间越长，单位时间内完成的事务越少，TPS 越低。

四、JMeter 聚合报告各字段对照解释

打开 JMeter 聚合报告，每一列含义：

表格

 

字段	含义
Samples	总请求数（计算 QPS 分母数据）
Average	平均响应时间 RT (ms)
Throughput	JMeter 自带吞吐量，这里展示的就是 QPS
Error%	错误请求占比

小知识点：

 

JMeter 本身不会自动统计 TPS；

 

想要统计 TPS 两种方式：

1. 把整套业务流程放入事务控制器，事务控制器的吞吐量就是 TPS；
2. 总事务次数 / 压测时长手动计算。

五、瓶颈场景举例（面试常考）

持续加大并发线程：

1. 并发从小到大：TPS、QPS 持续上升，RT 缓慢增加（系统正常负载区间）
2. 抵达系统临界点：TPS 不再上涨、QPS 封顶，RT 大幅变长，错误率开始上升（到达性能上限）
3. 继续加压：TPS 下降、大量报错，服务卡顿 / 宕机（系统崩溃）

六、简短面试口述版

QPS 是每秒单个接口请求次数，TPS 是每秒完整业务事务数；

 

一条业务链路包含多个接口，所以 QPS 一定大于 TPS；

 

JMeter 里普通接口吞吐量是 QPS，事务控制器吞吐量代表 TPS，可以通过总次数除以压测时间相互换算。