后端性能指标：QPS、TPS、RT、P95/P99 完整科普

步步糕升

做后端开发、接口压测、服务监控，一定会见到 QPS、TPS、RT、P95、P99、并发数、错误率这一堆名词。很多人容易把它们混为一谈。简单概括：QPS/TPS 看处理吞吐量，RT 看响应快慢，P 分位数看长尾体验，错误率看稳定性，资源指标用来定位瓶颈，可用性衡量整体服务可靠程度。

本文面向后端初学者、测试、运维人员，通俗讲解各项指标含义、相互关系以及常见踩坑误区。

一、QPS 与 TPS：别再搞混

QPS（Queries Per Second）每秒请求数

指系统每秒收到的请求数量，偏向接口、网络请求维度。一次 HTTP 调用、一次数据库查询，就记为一次 QPS。

举例：商品详情接口每秒被访问 1000 次，该接口 QPS=1000。

注意：一次完整的用户业务，会产生多次接口请求。比如用户下单，会依次调用查询商品、查库存、生成订单、扣减库存、调用支付接口，这一次下单业务会产生多条请求，对应多个 QPS。所以 QPS 高，不等于完成的业务多。
TPS（Transactions Per Second）每秒事务数

这里的 “事务” 不单单指数据库事务，代表一次完整闭环的业务操作，偏向业务结果维度。

举例：电商每秒成功成交 200 笔订单，下单 TPS=200。完成这 200 笔订单背后，接口 QPS 可能达到上千。

通俗生活化比喻：把系统比作一家餐厅

• QPS：每秒接收到的各类请求，点菜、催菜、加水、结账、问询，每一次交互都算一次 QPS；
• TPS：每秒真正完整上完菜、顾客完成用餐的桌数。
  

关键区分：QPS 统计 “来了多少次请求”；TPS 统计 “真正办成多少件完整业务”。只有单接口简单场景，QPS 才约等于 TPS。

二、RT 响应时间 & P95 / P99 分位数，不要只看平均值

RT（Response Time）响应时间：从发起请求，到收到完整返回结果的耗时，单位一般 ms 毫秒，RT 越小代表速度越快。

巨大坑点：平均值很有欺骗性。举个例子：100 次请求，99 次耗时 10ms，1 次耗时 10 秒。平均响应时间只有约 110ms，看起来性能尚可，但那 1% 的用户会遇到十几秒的卡顿。平均值掩盖长尾慢请求，线上故障很多就来自这一小部分慢请求。

所以生产环境重点看百分位分位数：

• P95：95% 的请求，响应时间小于该数值；仅有 5% 请求比这个更慢。代表绝大多数普通用户体验。
• P99：99% 的请求响应时间小于该数值，只剩 1% 请求更慢。这是高并发系统重点观测指标，少量慢请求会占满线程池、连接池，引发连锁雪崩。
• 更高还有 P999，用于核心金融、支付系统，关注极端最坏情况。
  

三、吞吐量、并发数，二者完全不一样

吞吐量

单位时间系统整体处理的工作量，含义随场景变化：

• Web 接口：每秒请求数；
• 消息队列：每秒处理消息条数；
• 数据库：每秒读写行数；
• 网络：每秒传输 MB 数据。
  

注意：不能孤立看吞吐量。吞吐量很高，但响应时间暴涨，说明系统已经超负荷在硬扛，用户体验会急剧恶化。

并发数

同一时刻，系统正在处理中的请求数量（正在干活，不是排队等待）。
有一个简易经验公式：并发数 ≈ QPS × 平均响应时间（单位秒）
举例：QPS=1000，平均 RT=0.1s，则系统同时在处理请求约 100 个。

启示：同样 QPS，如果接口响应越慢，占用的并发就越高，线程、连接池压力越大。优化 RT，不止提升体验，还直接降低系统资源压力。

四、错误率：吞吐量再高，错误率高毫无意义

错误率 = 失败请求 ÷ 全部请求。失败包含 HTTP5xx 服务异常、超时、业务逻辑失败、数据库报错等。

案例：秒杀接口每秒接收 10 万请求，但是 9 万请求全部报错超时。虽然 QPS 数字巨大，但系统实际已经被打垮，不能代表性能优秀。

业务等级不同要求不同：普通后台允许 0.1% 错误率；支付交易类核心链路，要求错误率控制在 0.01% 甚至更低。性能压测、线上监控，必须同时看成功率和吞吐量。
五、系统资源指标：定位瓶颈在哪里

性能故障表象是接口慢、报错，但根源经常体现在底层资源：

• CPU：计算、加解密、序列化、大量上下文切换，都会拉高 CPU；
• 内存：缓存过大、内存泄漏、大量临时对象分配；
• 磁盘 IO：数据库读写、大量日志输出；
• 网络带宽：大报文接口、文件传输；
• 连接池：数据库连接池、线程池耗尽，大量请求排队超时；
• GC（垃圾回收）：Java 应用，频繁 GC、STW 停顿会直接拉高 P99 延迟。
  

很多时候服务本身代码没问题，瓶颈出现在数据库、中间件、第三方依赖。

六、可用性（SLA）：系统能不能持续对外提供服务

可用性，系统正常对外服务的时间占总时间的百分比，行业习惯用 “几个 9” 描述华为云。
表格
可用性每年允许最大不可用时长典型业务场景
99.9%（3 个 9）8.76 小时普通业务系统
99.99%（4 个 9）52.56 分钟面向用户核心业务
99.999%（5 个 9）5.26 分钟金融、支付核心链路

可用性不等于性能。接口响应很快，但是经常宕机重启，可用性依旧很差；接口响应偏慢，但是全年极少故障，可用性反而很高。高可用依靠冗余、故障转移、限流熔断降级、监控告警共同保障。

七、其他重要配套指标

• 延迟与抖动：网络、直播、消息队列重点关注。抖动代表延迟忽快忽慢，哪怕平均延迟很低，抖动大，用户体验依然糟糕。
• 峰值容量：平时 QPS 一千，大促瞬间冲到五万。系统要具备应对流量尖峰的能力，依靠压测、缓存、队列削峰、自动扩容。
• 缓存命中率：缓存命中越高，越少请求穿透打到数据库。命中率过低会引发缓存穿透、击穿、雪崩风险，是互联网业务的关键观测点。
• 数据库相关指标：慢查询、锁等待、主从延迟、连接数。大量业务系统最终瓶颈都会落到数据库。数据库扩容难度远高于应用服务器横向扩容。
  

八、指标之间的连锁关系

线上系统各项指标是互相联动的：QPS 上涨 → RT 响应时间升高 → 并发数上涨 → CPU、连接池压力变大 → 错误率上升 → 可用性下降。

压测不要只追求最大 QPS 数字。必须附加约束条件，例如：P99<800ms，错误率 < 0.1% 前提下，最大 QPS 达到多少。脱离响应时间、错误率，单纯的 QPS 数字没有实际业务意义。压测环境还要确认：机器配置、数据量大小、是否命中缓存、数据库是否真实写入、网关日志、第三方依赖，否则压测结果好看，上线生产直接翻车。

常见认知误区澄清

• 误区：QPS 越高，代表业务处理能力越强纠正：QPS 只是请求数量，要看有多少请求真正完成业务（TPS），同时要看错误率和响应时间。
• 误区：看响应时间只看平均值就足够纠正：平均值会掩盖长尾慢请求，线上必须重点看 P95、P99 分位数。
• 误区：并发数就是同时在线用户数纠正：并发数是同一时刻正在处理的请求；在线用户很多只是挂着，不一定发起请求，二者概念不一样。
• 误区：压测跑出很高 QPS，上线就一定可以达到该数值纠正：压测环境经常是空数据库、全命中缓存；生产环境有真实数据、慢查询、第三方依赖，性能会下降。
• 误区：可用性 99.99% 代表接口很快纠正：可用性只衡量能不能正常服务，不衡量快慢，慢但不宕机，可用性也可以很高。
  

结语

简单回顾核心记忆点：

• QPS：统计来了多少次请求；TPS：统计办成多少完整业务；
• RT 看快慢，P95/P99 看长尾坏案例；
• 并发数、吞吐量看系统负载；错误率看稳定性；
• CPU / 内存 / IO 等资源指标，用来找到性能瓶颈；
• 可用性衡量整体服务可靠程度。
  

评估一套系统性能，不能拿单一数字下定论，要把吞吐量、响应分位数、错误率、资源水位结合起来综合判断。