压测目标与指标定义:从模糊到精确

做压测这么多年,我见过太多团队一上来就问:「能扛多少并发?」

这个问题其实很模糊。你想想看,没有目标就开跑,结果只能是自嗨。今天我们就聊聊,怎么把压测目标从「感觉」变成「数字」。

一、先搞清楚:我们为什么要压测?

我个人习惯,接到压测任务先问三个问题:

  • 这次压测要验证什么? 是新功能上线?还是大促保障?
  • 用户能接受多慢? 3秒还是300毫秒?
  • 系统崩了会怎样? 丢单?还是只是卡顿?

这三个问题回答清楚了,目标就出来了。说白了,压测目标 = 业务场景 + 用户容忍度 + 系统容错能力

核心原则: 压测目标必须可量化、可验证、可追溯。不要写「系统要稳定」,要写「单机2000 QPS下,RT < 200ms,错误率 < 0.1%」。

二、关键性能指标:五个数字定生死

做压测,你至少得盯住这五个指标。我当年第一次做全链路压测,就只看了QPS,结果RT飙到10秒都没发现……嗯,那次被批得很惨。

1. QPS(每秒查询数)

QPS 衡量的是系统处理请求的速度。它反映的是吞吐能力。

  • 计算公式:QPS = 总请求数 / 压测时长(秒)
  • 注意:QPS 高不代表系统好,还得看 RT。

2. TPS(每秒事务数)

TPS 和 QPS 经常被混用。我习惯这样区分:

  • QPS:一次请求就算一次查询
  • TPS:一个完整业务操作(比如下单)才算一个事务

举个例子:用户下单,前端发了3个请求(查库存、创建订单、扣余额)。QPS 是3,TPS 是1。你想想看,如果只看 QPS,你可能会误以为系统很强,其实一个用户都没完成下单。

3. RT(响应时间)

RT 是用户体验的直接体现。我一般关注三个值:

  • 平均 RT:整体感受,但容易被极端值拉偏
  • P99 RT:99%的请求都在这个时间内完成,这才是关键
  • P999 RT:千分之一的长尾请求,往往藏着问题

我的经验: 压测时别只看平均RT。有一次压测,平均RT只有200ms,但P99已经到2秒了。为什么?因为有少量请求走了慢SQL。如果只看平均,你根本发现不了。

4. 错误率

错误率 = 错误请求数 / 总请求数 × 100%。

常见的错误类型:

  • HTTP 5xx(服务端错误)
  • 超时(连接超时、读超时)
  • 业务错误(比如库存不足返回错误码)

注意: 错误率不是越低越好,而是要在可接受范围内。我见过有人把错误率压到0%,结果把超时时间设成了60秒……这其实是在掩耳盗铃。

5. 资源利用率

CPU、内存、磁盘IO、网络带宽。这些指标告诉你:瓶颈在哪

  • CPU 100% 但 QPS 上不去 → 计算密集型瓶颈
  • 内存飙升 → 可能有内存泄漏
  • 磁盘IO打满 → 数据库或日志写入有问题

三、SLA 与容量规划:把承诺变成数字

SLA(服务等级协议)说白了就是你跟用户之间的契约。比如:「我们保证99.9%的请求在500ms内返回」。

做容量规划时,我一般这样算:

  1. 预估峰值流量:比如双11的峰值是平时的10倍
  2. 设定安全水位:一般留30%-50%的余量
  3. 反向推算资源:单机扛1000 QPS,那10台机器就能扛1万 QPS

避坑指南: 我曾经遇到过,容量规划时只算了平均流量,结果大促时流量瞬间暴涨3倍,系统直接雪崩。后来我学乖了,容量规划一定要按峰值来算,而不是按平均值

四、压测通过标准:怎么才算「过」?

没有通过标准的压测,就是一场没有终点的马拉松。我建议至少包含以下几条:

指标 通过标准 说明
QPS/TPS 达到目标值 ±5% 比如目标5000 QPS,实际需 ≥ 4750
RT(P99) ≤ 目标值 比如目标200ms,实际需 ≤ 200ms
错误率 ≤ 0.1% 业务错误和系统错误分开统计
资源利用率 CPU ≤ 80%,内存 ≤ 70% 留有余量应对突发流量
稳定性 持续压测30分钟无异常 验证系统是否「稳」而不只是「快」

重要: 通过标准不是一成不变的。不同业务、不同阶段,标准可以调整。比如核心交易链路,错误率要求0.01%;而日志上报链路,错误率1%也能接受。

五、知识体系总览

下面这张图,把本章的核心逻辑串起来了。你可以把它当作压测目标定义的「检查清单」。

压测目标与指标定义 · 知识体系 压测目标定义 业务场景分析 关键性能指标 SLA与容量规划 压测通过标准 用户行为模拟 流量预估 QPS / TPS RT / 错误率 安全水位 资源反向推算 指标阈值 + 稳定性验证 核心:可量化 · 可验证 · 可追溯 从业务场景出发,用指标说话,用标准收尾

六、避坑总结

最后,分享几个我踩过的坑:

  • 别只压一个接口:全链路压测要覆盖核心业务流程,不是单接口压测
  • 别忽略冷启动:系统刚启动时性能差,等预热5分钟再开始记录数据
  • 别只看平均值:P99、P999才是用户真实体验
  • 别忘记监控:没有监控的压测,就像闭着眼睛开车

一句话总结: 压测目标定义,就是把「感觉」变成「数字」,把「大概」变成「精确」。你定义得越清楚,后续的瓶颈定位就越轻松。


公众号:蓝海资料掘金营,微信deep3321