性能测试指标

性能测试指标-并发

一个生活中的场景客户端就像是一个工厂，服务端就像是一个仓库，卡车就是并发的用户请求。

工厂会向仓库派遣卡车，拉取货物后返回工厂，这个其实就是客户端向服务端发起请求，服务端返回响应数据。

同时，每辆车将货物拉回工厂后，会继续进行下一趟拉货的流程，一直持续到业务结束。

定义：同时向服务器发送请求的用户数

几个容易混淆的概念

- 注册用户：在系统中注册成功的用户数量，也就是数据库里存储的用户数量

- 在线用户：同时处于在线状态的用户数量，也就是已经登录成功的用户数量

- 并发用户：同时向服务器发送请求的用户数量，也就是正在做同一个业务的用户数

在工厂的例子里，注册用户就是工厂里所有的卡车；在线用户就是已经派遣出去的卡车，但是车辆未必在拉货，可能在等待；并发用户就是正在拉货的卡车数量。

很明显，注册用户 > 在线用户 > 并发用户。

性能测试指标-TPS/QPS

Transaction Per Second，每秒钟处理的事务数。

在服务端接口性能测试中，事务Transaction可以理解成一次接口调用，所以TPS其实就是服务端每秒钟处理多少次接口调用。如果TPS越高，证明服务端项目的处理能力就越好，性能就越好。

在工厂的例子里。如果有很多卡车来拉货，假设仓库每秒处理1000辆卡车的货物，那就可以说仓库的TPS=1000，这个数值越大，证明仓库单位时间内处理的货物就越多，性能就越好。

性能测试指标-平均响应时间

一个请求的响应时间都包含哪些时间？

响应时间=网络传输的总时间+各组件业务处理时间

平均响应时间

响应时间Response Time，简称RT，指的是服务端处理完一个请求所花费的时间，通常时间单位为毫秒ms。

平均响应时间就是n多个请求响应时间的平均值。

平均响应时间越短，代表性能越好，TPS就越高。

银行办理业务的速度越快，单位时间内处理的业务量越多，因此性能就越好。

性能测试指标-TOP响应时间

将所有请求的响应时间先从大到小进行排序，计算指定比例的请求都是小于某个时间。该指标统计的是大多数请求的耗时。

Tp90（90%响应时间）：90%的请求耗时都低于某个时间

Tp95（95%响应时间）：95%的请求耗时都低于某个时间

Tp99（99%响应时间）：99%的请求耗时都低于某个时间

TPS、响应时间和并发数的关系

还是工厂的例子，站在仓库的角度来看，随着拉货的卡车越多，那同一时刻仓库的处理业务量就越大，但是仓库的处理能力总有一个上限，当卡车数量达到某个值后，处理能力就能达到巅峰。此时如果再来更多的卡车，仓库的处理能力也不会增加了，再来的卡车只能慢慢排队，所以响应时间就越来越长了。

在系统达到性能瓶颈之前，TPS和并发数成正比关系，即并发数越高，TPS越高；达到瓶颈后，并发数增加，TPS不会继续增高（甚至会下降），这个最高的tps出现的点，叫做拐点

TPS和平均响应时间成反比关系，即平均响应时间越小，TPS就越高

响应时间单位为秒的情况下

  TPS = 1 / 响应时间 * 并发数

  TPS = 并发数 / 响应时间

性能测试名词

1. 事务（Transaction）

核心定义：一次完整且不可拆分的业务操作流程，是性能测试的最小业务单元，满足 “原子性”（要么全成、要么全败）。

 

• 技术事务：数据库 BEGIN-COMMIT 操作，如一条 UPDATE 语句执行。
• 业务事务：用户视角的完整操作，如 “登录→查询商品→下单”，包含多个技术请求。
• JMeter 关联：通过事务控制器包裹多个 Sampler（HTTP/JDBC 请求），统计该流程的总耗时、成功率。

 

2. 吞吐量（Throughput） & 吞吐率

• 吞吐量：系统在一段时间内成功处理的总请求 / 事务 / 数据量，是宏观能力指标。
  • 单位：请求数、事务数、MB（数据传输量），如 “1 分钟处理 1200 笔订单”。
   
• 吞吐率：吞吐量的单位时间率值，和吞吐量本质是同一概念，日常表述中常混用。
  • 单位：请求 / 秒、事务 / 秒、MB / 秒，如 “吞吐率 20 订单 / 秒” = “每秒吞吐量 20 订单”。
   
• 核心关联：
  • 当统计口径为事务时，吞吐率 = TPS；
  • 当统计口径为请求时，吞吐率 = RPS/QPS；
  • 当统计口径为数据时，吞吐率 = 网络传输速率（如 MB / 秒）。
   

 

3. 核心速率指标（TPS/QPS/RPS/HPS）

 

指标	全称	定义	适用场景	关联关系
TPS	Transactions Per Second	每秒完成的完整事务数	业务流程测试（支付、下单、转账）	1 个 TPS = 多个 RPS/QPS（1 个业务事务包含多请求）
QPS	Queries Per Second	每秒完成的查询类请求数	读操作场景（数据库 SELECT、缓存 GET）	QPS 是 RPS 的子集（仅统计查询请求）
RPS	Requests Per Second	每秒完成的HTTP/API 请求数	Web / 接口测试（所有类型请求）	最通用的技术指标，包含 QPS
HPS	Hits Per Second	每秒完成的页面点击数	传统 Web 前端测试	1 次 Hits 可能触发多个 RPS（如打开网页加载 CSS / 图片），现在基本被 RPS 替代

 

4. 网络（Network）

性能测试中，网络是系统能力的关键约束，和吞吐量、速率指标直接挂钩，核心监控维度：

 

• 带宽利用率：实际使用带宽 / 总带宽，超过 90% 会出现网络拥塞，导致请求超时。
• 网络吞吐量：单位时间内网络传输的数据量（MB / 秒），受带宽、网卡性能、网络延迟影响。
• 延迟 / 抖动：网络延迟高会拉长单请求耗时，间接降低 RPS/TPS（系统在等网络响应，无法处理新请求）。
• 关联逻辑：网络瓶颈会先于服务器瓶颈出现 → 即使 CPU / 内存空闲，网络拥塞也会导致吞吐量无法提升。

 

5. 资源利用率（Resource Utilization）

 

系统硬件 / 软件资源的使用占比，是定位性能瓶颈的核心依据，决定了吞吐量和速率指标的上限。

 

资源类型	核心监控指标	常用瓶颈阈值	对性能的影响
CPU	使用率（%）、负载（load average）	持续 > 85%	CPU 跑满时，无法处理新请求，TPS/RPS 不再增长甚至下降
内存	使用率（%）、交换分区（Swap）使用率	内存 > 90% + Swap > 20%	内存不足会触发磁盘交换，请求耗时剧增
磁盘	IO 使用率（%）、读写吞吐量	持续 > 80%	磁盘 IO 瓶颈会拖慢数据库、日志写入等操作
数据库	连接数使用率、锁等待率、慢查询数	连接数 > 80%	数据库瓶颈会直接限制业务事务的处理速度
网络	带宽利用率、网卡收发速率	带宽 > 90%	见上文 “网络” 部分