[TOC]

性能测试基础

性能测试指标

并发用户数

• 在同一时间段内，与系统进行交互（发送请求、等待响应或处于思考时间）的活跃用户数量

  定义:同一时刻，系统同时处理的多个用户请求的数量

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

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

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

例子详解

• 场景 1：在线会议系统（如 Zoom 小规模会议）

  • 含义： 同时开启摄像头/麦克风、共享屏幕或实时聊天的活跃参会者数量
  • 典型指标：
    • 设计目标：稳定支持 50 个并发用户（活跃参与者）进行音视频交互
    • 问题场景：当并发用户数达到40时，部分用户开始反映视频卡顿、音频断续。服务器监控显示网络出口带宽已饱和。这表明系统在40并发时带宽成为瓶颈，无法达到 50 并发的目标

• 场景 2：后台管理系统（如订单审核）

  • 含义： 同时登录系统并在执行操作（查询订单、审核、导出数据等）的管理员数量
  • 典型指标：
    • 日常负载：平均 20 个并发管理员
    • 峰值负载：月底结算时，预计 50 个并发管理员同时操作
    • 问题场景：月底 50 并发时，订单查询页面加载极慢（响应时间 > 10s），导出功能频繁失败。数据库监控显示 CPU 和磁盘 IO 持续 100%。这表明数据库无法支撑 50 个并发管理员的操作负载

PV（Page View）

定义：页面/接口的访问量

UV（Unique View）

定义：页面/接口的每日唯一访客（每日活跃用户）

吞吐量(Throughput)

定义：单位时间内系统处理的请求数量或数据量（如：订单数/秒、登录成功次数/分钟、生成报告份数/小时）

例子详解

• 场景 1：在线支付网关

  • 业务量： 成功处理的支付交易笔数。
  • 吞吐量指标： TPS (Transactions Per Second) - 每秒成功处理的支付交易笔数
  • 典型指标：
    • 目标值： 日常峰值 TPS >= 1000。大促目标 TPS >= 5000。
    • 问题场景： 在模拟 3000 TPS 的压力下，实际 TPS 只能达到 1200，且响应时间飙升。瓶颈分析发现支付核心服务的数据库写入慢，无法跟上请求节奏。

• 场景 2：新闻资讯 App 内容推送

  • 业务量：成功发送给用户的推送消息条数
  • 吞吐量指标：Messages Per Minute (MPM) - 每分钟成功发送的消息条数
  • 典型指标：
    • 目标值：突发新闻时，MPM >= 100, 000（10万条/分钟）
    • 问题场景：重大事件发生时，实际 MPM 只有 30, 000。分析发现消息队列的消费者服务实例不足，处理速度跟不上消息生产速度，导致队列积压

• 场景 3：批量报告生成服务

  • 业务量：成功生成并存储的报告文件份数
  • 吞吐量指标：Reports Per Hour (RPH) - 每小时成功生成的报告份数
  • 典型指标：
    • 目标值：RPH >= 500（满足每日批量作业需求）
    • 问题场景：实际 RPH 只有 200。分析发现生成一份报告需要访问多个外部系统，这些外部调用的响应时间过长且无法并行化

TPS/QPS

定义：Transaction Per Second，每秒处理的业务事务数量（无论成功与否）

• 在服务端接口性能测试中，事务Transaction可以理解成一次接口调用
• TPS就是服务端每秒处理多少次接口调用
• TPS越高，服务端项目处理能力越好，性能越好

例子详解

• 与吞吐量 (Throughput) 区别：

  • RPS/QPS： 客户端发出的请求频率。 包含了成功和失败的请求
  • TPS： 服务器成功处理的业务量频率。 只计算成功完成业务逻辑的

• 场景 1：社交媒体 API 网关

  • 指标：QPS-每秒到达 API 网关的 HTTP 请求总数（GET/POST/PUT/DELETE 等）
  • 典型指标：
    • 监控重点：日常波动范围，峰值 RPS（如明星发帖时）
    • 问题场景：系统设计容量为 10, 000 RPS。在 8, 000 RPS 压力测试时，平均响应时间从 50ms 升至 2s，错误率（HTTP 5xx）上升到 20%，而 TPS（如成功发布帖子的操作）停滞在 1, 500 TPS。这表明系统在 8, 000 RPS 下实际有效处理能力只有 1, 500 TPS，大量请求超时或失败

• 场景 2：商品搜索服务

  • 业务量：QPS-每秒到达搜索服务的查询请求数（如 Elasticsearch 的搜索请求）
  • 典型指标：
    • 容量评估：单个搜索节点能支撑的 QPS（如 5, 000 QPS）
    • 问题场景：促销期间商品搜索 QPS 达到 8, 000。监控显示搜索集群 CPU 饱和，平均查询延迟从20ms飙升至500ms，部分查询超时失败。需要增加搜索节点分担负载

响应时间

• 用户从发起请求到接收到完整响应所经历的总时间

定义：响应时间=网络传输的总时间 + 各组件业务（中间件+应用程序+DB）处理时间 + 客户端渲染时间（对于 Web 页面）

• 响应时间Response Time，简称RT，指的是服务端处理完一个请求所花费的时间，通常时间单位为毫秒ms
• 平均响应时间就是n多个请求响应时间的平均值
• 平均响应时间越短，代表性能越好，TPS就越高
• 通常关注：平均响应时间、第 90 百分位数 (P90)、第 95 百分位数 (P95)、第 99 百分位数 (P99)、最大响应时间

例子详解

• 场景 1：电商商品详情页加载

  • 用户操作：用户点击某个商品链接
  • 测量点：从点击链接到浏览器完整渲染出商品图片、标题、价格、描述、评论等信息，用户可以滚动页面为止
  • 典型指标：
    • 目标值：平均加载时间 <= 2秒， P95 <= 3秒
    • 问题场景：大促期间，平均加载时间升至 5秒， P95 达到 10秒。用户大量流失。分析发现瓶颈在于获取商品评论的 API 响应慢（平均 3.5秒），因为评论数据库查询未优化，且缓存失效

• 场景 2：银行转账 API

  • 用户操作：用户在手机银行 App 上输入金额，点击“确认转账”
  • 测量点：从 App 发送转账请求到接收到服务器返回“转账成功”或“失败”的明确结果
  • 典型指标：
    • 目标值： 平均响应时间 <= 800ms， P99 <= 1500ms（金融交易对延迟要求高）
    • 问题场景：用户反馈转账时经常卡顿。监控显示该 API P99 高达 4秒。APM 工具追踪发现，75% 的时间消耗在调用一个外部风控系统进行实时校验上，该风控系统自身存在性能瓶颈

• 场景 3：搜索建议 (Auto-Complete)

  • 用户操作：用户在搜索框中输入字符（如 “lap”）
  • 测量点：从用户输入一个字符到下拉框显示出匹配的建议结果（如 “laptop”, “laptop bag”）的时间
  • 典型指标：
    • 目标值：平均响应时间 <= 100ms。用户期望即时反馈
    • 问题场景：用户输入后感觉明显卡顿。测量发现平均响应时间为 350ms。分析发现搜索建议查询了全量数据库而非内存缓存，且前端未做防抖处理导致请求过多

TOP响应时间

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

• TP90（90%响应时间）：90%的请求耗时都低于某个时间
• Tp95（95%响应时间）：95%的请求耗时都低于某个时间
• Tp99（99%响应时间）：99%的请求耗时都低于某个时间

事务成功率 (Transaction Success Rate / Pass Rate)

定义：在单位时间内（或总事务量中），成功完成预期业务目标的事务数 所占的百分比

• 错误率：关注单个请求/操作的失败率（技术层面）。

• 事务成功率：关注完整业务流程（由多个请求组成）的成功率（业务层面）。

  • 例如：一个“下单”事务可能包含：添加商品到购物车 -> 进入结算页 -> 提交订单 -> 支付。即使中间某个请求成功了（如添加购物车），但如果最终支付失败，整个“下单”事务就算失败

例子详解

• 场景 1：电商购物车结算流程

  • 事务定义：用户从点击“结算”开始，到最终看到“支付成功”页面结束
  • 成功标准：用户完成支付并收到成功确认
  • 成功率指标：*(成功完成支付流程的会话数 / 发起结算的会话总数) 100%**
  • 典型指标：
    • 目标值：>= 98% (流失率 < 2%)
    • 问题场景：大促期间，结算成功率跌至 85%。分析发现：
      • 15% 的用户在“提交订单”步骤失败（数据库锁竞争导致更新库存超时）。
      • 5% 的用户在“调用支付网关”步骤失败（支付网关响应慢导致超时）。虽然单个步骤错误率不算极高，但组合起来导致整体事务成功率大幅下降

• 场景 2：用户注册流程

  • 事务定义：用户从填写注册表单开始，到点击提交，最终收到激活邮件/短信并成功激活账号
  • 成功标准：账号成功创建并激活
  • 成功率指标：*(成功激活的账号数 / 提交注册表单的用户数) 100%**
  • 典型指标：
    • 目标值：>= 90%
    • 问题场景：成功率只有 75%。分析发现：
      • 10% 在提交表单时失败（表单验证 API 错误）。
      • 15% 的用户未收到激活邮件（邮件发送服务队列积压或失败）。这反映了注册流程中后端服务的可靠性问题

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

定义：系统到达瓶颈前，TPS和并发数成正比，并发数越高，TPS越高；达到瓶颈后，TPS不会再继续增高（甚至会下降），最高的TPS出现的点，称之为拐点

• 响应时间单位为秒S的情况下：
  • TPS = 1并发/响应时间*总并发数
  • TPS = 并发数（总请求数） / 响应时间

例子：
场景：10个并发，压测一个接口，平均响应时间0.5秒，那么tps=？
tps指的是每秒种接口的总调用次数

1.10个并发之间是相互独立的
2.先计算1个并发每秒种能调用多少次：1/0.5=2
3.10个并发每秒种能调用多少次：2 * 10=20
tps = 10 / 0.5 = 20

性能监控指标

• 技术指标：如sql耗时不能超过200ms；fgc在多少时间范围内不能超过多少次；服务器资源使用情况

操作系统级别监控

• CPU使用率、内存使用率、网络IO（input/output）、磁盘（read/write/util）

中间件监控

• 连接数、长短连接、使用内存

应用层监控

• 线程状态、JVM参数、GC频率、锁

DB监控

• 连接数、锁、缓存、内存、SQL效率