性能指标体系：关键性能指标（KPI）定义

做性能优化，第一件事不是撸起袖子改代码。

你得先搞清楚一件事——到底什么是「好」？

没有指标，优化就是瞎猫碰死耗子。我在项目中见过太多团队，一上来就怼并发、压吞吐，结果忙活一个月，用户该卡还是卡。为什么？因为他们连「响应时间」和「吞吐量」的关系都没理清。

这一章，咱们就把性能指标体系彻底讲透。

1. 响应时间（Response Time）

响应时间，说白了就是用户点一下按钮，到看到结果，中间等了多久。

我习惯把它拆成三段：

• 网络传输时间：数据在客户端和服务端之间跑路的时间
• 服务端处理时间：CPU 算、内存读、磁盘写，真正干活的时间
• 客户端渲染时间：浏览器或 App 把数据变成画面的时间

你想想看，用户感知到的「慢」，往往是这三段加起来的总和。但很多工程师只盯着服务端，忽略了前端渲染——我曾经踩过这个坑。

2. 吞吐量（Throughput）

吞吐量，就是单位时间内系统能处理多少请求。

常见的单位有：

• QPS（Queries Per Second）—— 每秒查询数，适合读场景
• TPS（Transactions Per Second）—— 每秒事务数，适合写场景
• RPS（Requests Per Second）—— 每秒请求数，通用指标

吞吐量和响应时间，其实是跷跷板的两头。你压得越狠，响应时间往往就越长。我见过有人把 QPS 压到极限，结果响应时间飙到 10s 以上——这有什么意义呢？

3. 并发数（Concurrency）

并发数，就是同一时刻系统正在处理的请求数量。

很多人把并发数和吞吐量搞混。我举个例子：

• 并发数 = 餐厅里同时吃饭的人数
• 吞吐量 = 每小时能接待多少桌客人

并发数高了，不代表吞吐量就高。如果每个请求都慢得像蜗牛，并发数再大也没用。

并发数 = 吞吐量 × 平均响应时间

我在项目中遇到过一个问题：系统并发数到了 500，CPU 才用了 30%，但响应时间已经飙到 3s 了。后来发现是数据库连接池太小，线程都在等连接。你看，并发数高不一定代表资源用得好。

4. 资源利用率（Resource Utilization）

资源利用率，就是 CPU、内存、磁盘、网络这些硬件被用了多少。

我习惯看这几个：

5. 错误率（Error Rate）

错误率，就是所有请求中，返回错误的比例。

常见的错误类型：

• HTTP 5xx —— 服务端内部错误
• HTTP 4xx —— 客户端请求错误（但有时也是服务端配置问题）
• 超时 —— 请求没在规定时间内返回
• 业务错误 —— 比如下单失败、支付失败

我一般把错误率分成两个等级：

• 硬错误：系统挂了，必须立刻处理。比如 500 错误率超过 1%
• 软错误：业务逻辑异常，比如库存不足。这类错误需要分析，但不一定紧急

6. 指标之间的关系

这几个指标不是孤立的。我画了一张图，帮你理清它们的关系：

你看这张图就明白了：

• 响应时间和吞吐量是反比关系——你压得越狠，响应时间越长
• 并发数和响应时间通过 Little's Law 关联——并发数 = 吞吐量 × 响应时间
• 资源利用率高了，响应时间就会变差——CPU 满了，请求就得排队
• 错误率往往是其他指标恶化的结果——响应时间长了，超时错误就多了

嗯，指标体系就讲到这里。下一章咱们聊聊怎么搭建性能监控平台，把这些指标真正用起来。