性能指标定义：响应时间、吞吐量、并发用户数、资源利用率、错误率

做性能测试这么多年，我见过太多团队一上来就闷头跑压测。结果呢？数据跑了一大堆，问他们「你的系统到底多快？」——没人说得清。

说白了，就是没把指标定义清楚。

今天咱们就把这五个核心指标掰开揉碎了讲。每个指标我都会结合真实项目经验，告诉你它到底怎么用、坑在哪。

响应时间，就是从用户发出请求到收到完整响应的时间。我习惯把它拆成三段：

你想想看，用户说「慢」，到底是哪一段慢？

关键指标：

我的经验：有一次给电商平台做压测，平均响应时间才200ms，看起来很美。但一查P99，好家伙，直接飙到3秒。后来发现是某个慢SQL在特定数据量下才触发。所以，只看平均值会骗人。

吞吐量衡量的是系统在单位时间内能处理多少请求。常见的单位有：

我个人习惯在接口层面用RPS，在业务场景层面用TPS。举个例子：

// 一个下单事务包含：
// 1. 查询商品详情（1个请求）
// 2. 创建订单（1个请求）
// 3. 扣减库存（1个请求）
// 4. 支付（1个请求）
// 这个事务的TPS = 1，但RPS = 4

注意：吞吐量和响应时间是一对冤家。系统吞吐量上去后，响应时间通常会变差。我见过有人把吞吐量压到极限，结果响应时间从200ms变成5秒——这其实已经不可用了。

并发用户数，指的是同一时刻系统正在处理的用户数量。注意，是「正在处理」，不是「在线用户数」。

我曾经遇到一个客户，说他们系统有10万在线用户，要求并发支持5万。我一听就知道有问题。实际上，在线用户里大部分是挂着的，真正在操作的也就10%-20%。

避坑指南：我曾经帮一个金融项目做评估，他们按在线用户数的50%来设计并发。结果上线第一天就挂了。后来我们按业务高峰期的实际日志来算，发现并发只有在线用户的3%。所以，别拍脑袋，看数据。

资源利用率，就是CPU、内存、磁盘、网络这些硬件被用了多少。我一般关注这几个：

嗯，这里要注意：资源利用率不是越高越好。CPU跑到99%不代表系统性能好，可能只是代码写得烂。

我的判断逻辑：

错误率，就是失败请求占总请求的比例。我一般分两类看：

为什么会这样？因为很多团队只看HTTP状态码，忽略了业务错误。我曾经遇到一个支付系统，压测时接口返回全是200，但实际有30%的订单支付失败——业务错误码藏在响应体里。

我的经验：错误率超过1%就要立即停止压测，排查原因。别想着「再压一会儿看看」，系统可能已经处于崩溃边缘。有一次我坚持继续压，结果数据库连接池被打爆，整个服务挂了20分钟。

下面这张图，是我梳理的五个指标之间的关系。你看一眼就能明白：

说白了，这五个指标就像汽车的仪表盘。响应时间是速度表，吞吐量是里程表，并发用户数是载重表，资源利用率是油温表，错误率是故障灯。少看一个，都可能翻车。

最后说一句：定义指标只是第一步。真正重要的是，你要知道每个指标的合理范围是多少。这个范围，就是你的性能基线。下一章，我会教你怎么搭建这个基线。

想要更多资料，联系可可