第三章 性能指标体系：看懂数字背后的真相

做性能测试这些年，我最大的体会是——不懂指标，就是在黑暗中乱摸。响应时间快了还是慢了？系统到底能扛多少人？光凭感觉没用，得靠数据说话。但指标也不是越多越好，关键是抓到那几个核心的。

这一章，我把性能领域最常用的六个指标掰开了讲。每个指标我都会说说它背后的逻辑，以及在实际项目中怎么用。你想想看，要是连这些都没搞清楚，搭建出来的基线你敢信吗？

3.1 响应时间——用户的耐心刻度

响应时间，就是从用户发出请求到收到完整响应所花的时间。说白了，用户等不等得起，就看它。

我在项目中遇到过一家电商客户，首页加载平均耗时 3.8 秒，业务方说"还行吧"。结果我用 APM 工具一拆，发现后端接口只用了 200 毫秒，剩下全耗在了前端资源加载和图片渲染上。你想想，用户等 4 秒看一张大图，早关页面了。

衡量响应时间，别只看平均值。我习惯同时关注 中位数和高峰时段，这样才能抓到真实体验。

3.2 吞吐量——系统的输油管

吞吐量，单位时间内系统能处理的请求数量。常见的有 TPS（每秒事务数）和 QPS（每秒查询数）。

我个人习惯把吞吐量想象成一根输油管——管径再粗，一旦油压上来，流量就上不去了。很多时候响应时间没涨多少，吞吐量却先到了天花板。这就是瓶颈的信号。

遇到吞吐量上不去的情况，先查资源利用率，再查锁竞争。这是我最常用的排查路径。

3.3 并发用户数——别被数字骗了

并发用户数，指同一时刻活跃的用户数量。注意，不是在线人数，是真正在发请求的那些。

我曾经踩过一个坑：测试报告里写着"支持 5000 并发"，结果上线当天就被打穿了。后来一查，测试工具模拟的是均匀发请求，真实用户却是突发式的——高峰时并发量翻了两倍还多。

3.4 资源利用率——成本与瓶颈的交叉点

资源利用率，主要指 CPU、内存、磁盘 I/O 和网络带宽的使用百分比。它直接告诉你——系统到底吃饱了没有？

很多人盯着 CPU 看，觉得 80% 以下就安全。其实不一定。我见过一个系统 CPU 只有 35%，但磁盘 I/O 队列已经排到 200 了。说白了，瓶颈往往藏在你不注意的那个资源里。

监控资源利用率，我建议至少盯住 CPU 使用率、内存占用、磁盘 I/O 等待时间这三项。哪一项先到 80% 以上，哪一项就是你的下一块短板。

3.5 错误率——系统健康的晴雨表

错误率，就是请求失败的占比。HTTP 5xx、超时、连接拒绝……都属于错误。

我曾经在压测时看到错误率只有 0.5%，觉得可以接受。结果一查日志，发现所有错误都集中在支付接口——虽然只占 0.5%，但那可是真金白银的交易啊。从那以后，我养成了一个习惯：不仅看错误率，还看错误分布。

一般建议，性能测试期间错误率要 低于 1%，关键业务接口必须为 0%。

3.6 百分位——剔除噪音，看清真相

百分位，就是把所有响应时间排个序，取第 P50、P90、P95、P99 的值。它比平均值靠谱得多。

举个例子：100 个请求里，99 个花了 100 毫秒，1 个花了 10 秒。平均响应时间 ≈ 200 毫秒，看起来不错。但 P99 是 10 秒——这才是真实伤害。

我一般这样看百分位：

• P50（中位数）：大多数用户的体验，日常关注
• P90 / P95：边缘用户的体验，用来发现潜在问题
• P99（尾延迟）：最差情况，系统稳定性的底线

性能指标对比总览

六个指标各有侧重，放在一起看才完整。这张表帮你快速对照：

指标	定义	核心关注点	常用工具/方法
响应时间	请求到响应的总时长	用户体验	APM 工具、埋点
吞吐量	单位时间处理的请求数	系统处理能力	TPS / QPS 统计
并发用户数	← 上一章 📖 返回目录 下一章 →