知识卡片
QPS陷阱：用资源而非请求数衡量容量
内容
用每秒请求数（QPS）规划服务容量看似直观，实则是陷阱：不同请求消耗的资源可能天差地别，且会随 客户端实现、时段、版本无声漂移——某 QPS 阈值今天良好，一次代码变更让请求成本骤变也可能使它 失效。更稳健的做法是直接用可用资源（CPU核心数、内存）衡量容量，把每请求”成本”定义为它消耗 的 CPU 时间。发散：这与[[基于意图而非具体数字做资源规划]]同属”用不变的资源度量代替易变的 计数代理”。
参考来源
- 位置：《SRE：Google运维解密》第21章《应对过载》"QPS陷阱"一节（源文件：_epub-src/OEBPS/Text/0009_0012.xhtml）
- 结论依据：原文明确"按照QPS来规划服务容量……一般是错误的选择。就算这个指标在某一个时间段内看起来工作还算良好，早晚也会发生变化"，并给出替代方案"直接以可用资源来衡量可用容量……将某个请求的'成本'定义为该请求……所消耗的CPU时间"。
- 原始内容：Google在多年的经验积累中得出：按照QPS来规划服务容量……一般是错误的选择……更好的解决方案是直接以可用资源来衡量可用容量。例如，某服务可能在某个数据中心内预留了500 CPU 内核和1TB内存用以提供服务。