QPS：衡量请求流入速度
全称：Queries Per Second（每秒查询/请求数）
核心含义：1秒钟内用户向服务器发起的请求次数，直接反映流量压力与访问速率。
资源消耗：主要消耗CPU资源。QPS越高，CPU负载越重，容易达到瓶颈。
示例：QPS=200，意味着每秒涌入200次请求。
RT：衡量接口响应效率
全称：Response Time（响应时间）
核心含义：从用户发起请求到服务器返回结果的总耗时（单位：秒/毫秒）。包含网络传输、代码运算、数据库查询及第三方接口等待时间。
业务影响：代表接口性能及业务卡顿程度。RT越高，接口越慢，请求积压越严重。
示例：RT=0.3s，表示用户点击按钮后需等待0.3秒才能看到结果。
为何优先关注P95 RT而非平均值？
排查性能问题时，应重点关注P95 RT（95分位响应时间），而非简单的平均值。
- 计算逻辑：将一段时间内所有请求的响应耗时从小到大排序，取总请求数×0.95位置对应的耗时值。
- 统计意义：95%的请求响应时间小于该数值，仅有5%的请求更慢。
- 实际价值：平均RT易被大量快速请求“拉低”，从而掩盖少数极端慢请求。P95 RT能真实反映较差的用户体验，因为少数慢请求往往是导致并发飙升、诱发线上故障的关键因素。
并发：衡量系统瞬时负载
核心含义：同一瞬间，服务器正在处理或等待中的请求总数。
资源消耗：代表连接压力、进程压力及内存压力。
风险提示：并发过高会耗尽进程池、数据库连接等资源，导致502/504错误或服务卡顿。
常见误区：并发 ≠ 在线用户数
数百人仅挂着页面而不进行操作，不会产生任何并发压力。只有真正发起HTTP请求的行为才会计入并发。
核心公式与案例分析
万能公式：并发 = QPS × RT（RT单位为秒）
该公式揭示了系统压力的本质：请求来得越快（QPS高）且处理得越慢（RT高），积压的并发量就越大。
案例对比
案例1：高效处理
- 条件：RT=0.1s，QPS=200
- 计算：并发 = 200 × 0.1 = 20
- 结论：尽管流量较大，但因处理极快，服务器毫无压力。
案例2：慢速阻塞
- 条件：RT=2s（存在慢SQL或IO阻塞），QPS=200
- 计算：并发 = 200 × 2 = 400
- 结论：流量看似一般，但因处理过慢，导致请求大量积压，直接打满进程，引发系统卡死。
指标与服务器瓶颈对应关系
不同指标异常对应不同的系统瓶颈，需针对性优化：
- QPS过高：表现为CPU爆满、服务器负载高、接口响应变慢。对策通常为增加CPU核心数或优化算法。
- RT过高：表现为慢SQL、代码逻辑卡顿、IO阻塞、第三方接口超时。这是导致并发爆炸的主要原因，系统卡顿90%源于此。
- 并发过高：表现为进程占满、连接数打满、内存溢出、服务雪崩，甚至出现网站无法打开、502报错、超时等现象，此时CPU使用率可能反而很低。
总结与建议
QPS、RT和并发是评估服务稳定性的三大核心维度：
- QPS代表请求流入速度，主要消耗CPU；
- RT代表接口处理效率，直接决定请求积压程度；
- 并发代表系统瞬时负载，消耗进程、连接与内存资源。
依据公式并发=QPS×RT可知，系统崩溃并非总是因为QPS过高。即便流量不大，若RT过高，也会导致并发暴涨，进而引发502、超时等故障。
在进行服务器选型和故障排查时，切勿仅关注在线用户数。应重点监控峰值QPS、P95 RT以及由此计算的峰值并发，并预留合理的资源冗余，以保障业务的长期稳定运行。
#性能优化 #QPS