第2章关键性能指标(KPI)

关键性能指标：响应时间、吞吐量、并发用户数、资源利用率、QPS、TP99

性能建模这件事，说白了就是先搞清楚「我们要衡量什么」。没有指标，架构决策就是拍脑袋。我见过太多团队，一上来就堆机器，结果瓶颈根本没找到。嗯，今天咱们就把这几个核心KPI掰开揉碎讲清楚。

响应时间，就是从用户发出请求到收到完整响应所花的时间。我习惯把它拆成三部分：网络传输时间、服务处理时间、数据访问时间。

你想想看，用户点一下按钮，等了两秒还没反应，他大概率就关页面了。我在电商项目中遇到过，首页加载从800ms涨到1.2s，转化率直接掉了5%。这就是响应时间的威力。

  测量要点：
  前端响应时间：从浏览器发出请求到DOM渲染完成
后端响应时间：从网关收到请求到返回响应
端到端响应时间：用户真实感知的完整链路

我的习惯： 在代码里埋点，用日志记录每个接口的P50、P90、P99响应时间。别只看平均值，平均值会骗人。

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

这三个概念容易混淆。我简单解释一下：

我曾经帮一个金融项目做压测，他们的TPS只有200，但业务要求是1000。后来发现是数据库连接池配小了，线程都在等连接。调大连接池后，TPS直接飙到1200。你看，有时候问题就这么简单。

并发用户数，不是「注册用户数」，也不是「在线用户数」。它指的是同一时刻正在与系统交互的用户数量。

举个例子：一个直播间有10万人同时在线，但真正在发弹幕、点赞、刷礼物的可能只有5000人。这5000人才是并发用户数。

我曾经踩过的坑： 把在线用户数当并发用户数来设计架构。结果压测时发现，10万在线用户产生的并发请求只有3000，但系统按10万去设计，白白浪费了资源。后来我学乖了，用「活跃用户比例」来估算真实并发。

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

我个人习惯，CPU利用率超过70%就开始预警。为什么？因为一旦有突发流量，系统可能直接被打满。留点余量，心里踏实。

QPS，每秒查询数。它其实是吞吐量的一种特例，专门针对查询场景。在互联网架构里，QPS几乎是出镜率最高的指标。

怎么算？很简单：

QPS = 总请求数 / 时间（秒）

举个例子：
1分钟处理了6000个请求
QPS = 6000 / 60 = 100

  实战经验： 我一般用QPS来评估系统容量。比如一个接口的QPS上限是500，业务预估峰值是400，那就要考虑扩容或者限流了。别等到QPS打满才动手，那时候已经晚了。

TP99，意思是99%的请求响应时间都在这个值以内。比如TP99=200ms，说明99%的请求在200ms内完成，只有1%的请求超过200ms。

为什么看TP99而不是平均值？我举个例子：

平均值看起来还行，但TP99暴露了那个「慢请求」的存在。在线上，这1%的慢请求可能就是用户体验的致命伤。

我的建议： 监控系统里至少要看P50、P90、P99三个分位值。P50代表典型体验，P90代表大多数用户，P99代表最差的那批用户。如果P99比P50高了一个数量级，说明系统存在严重的「长尾延迟」问题。

下面这张图，是我梳理的KPI核心关系。你看一眼就能明白它们之间的关联：

指标定义清楚了，怎么测？我分享几个实战经验：

注意： 测量本身会带来性能开销。比如全链路追踪如果采样率太高，反而会影响响应时间。我一般把采样率控制在1%-10%，线上环境用自适应采样。

好了，这些KPI就是性能建模的「度量衡」。搞清楚了它们，你才能说「我的系统性能好不好」。下一节，咱们聊聊怎么用这些指标来指导架构设计决策。