Skip to content

QPS(Queries Per Second,每秒查询率) ​

看在前面 ​

一句话描述 ​

每秒查询率,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

展开说:QPS 统计的是服务器每秒处理的请求数,是技术侧最基础的容量/性能指标。它和 PV 这类业务指标描述的对象不同。PV 说明"业务有多火",QPS 说明"系统每秒实际扛了多少请求、还能扛多少"。

一、定义与计算 ​

基本公式:

QPS = 统计窗口内处理的请求总数 ÷ 窗口秒数

例:某接口 1 分钟内处理了 12000 次请求,QPS = 12000 ÷ 60 = 200。

与 TPS 的区分:

  • TPS(Transactions Per Second,每秒事务数):一个事务是指一个客户机向服务器发送请求然后服务器响应的过程。客户机在发送请求时开始计时,收到服务器响应后结束计时。以此计算使用的时间和完成的事务个数。每个事务包括 3 个过程。①用户请求服务器。②服务器内部处理(应用服务器、数据库服务器等)。③服务器返回给用户。如果每秒能够完成 N 次这三个过程,TPS 就是 N。有时会将多个请求定义为一个事务,完成一次就算一个 TPS;
  • QPS(Queries Per Second,每秒查询率):一台服务器每秒能够响应的查询次数。它衡量特定查询服务器(如读写分离架构里的读服务器)在规定时间内处理的流量;
  • 一个事务(Transaction)可以包含多个请求(Query)。对一个页面请求一次形成 1 个 TPS。但一次页面请求可能产生多次对服务器的请求(如页面图片等资源),这些请求计入 QPS;
  • 前后端分离架构下默认讨论的是服务端接口性能。对单接口压测且该接口内部不再调用其他接口时,TPS = QPS;否则不等;
  • 混合场景压测(JMeter)要加事务控制器,统计出的才是整个场景的 TPS,聚合报告里的 Throughput 即吞吐量。

qps&tps

二、QPS 与 PV / RT 的关系 ​

与 PV 的关系是累计量与瞬时速率的关系,容量规划里常用的换算:

峰值 QPS ≈ 日 PV ÷ 86400 × 集中系数 × 每页触发请求数

假设一天 1 亿 PV:平均下来约 1157 次/秒,但流量不均匀。访问集中在 20% 的高峰时段(二八法则),一次页面打开还会触发多个接口请求。实际峰值 QPS 可能是平均值的几倍到几十倍。容量设计永远按峰值 QPS 折算,而不是按日均 PV。

与 RT(Response Time,单次请求耗时)的关系是个跷跷板:

QPS ≈ 并发数 ÷ 平均 RT

同样的并发能力下,RT 从 100ms 优化到 50ms,可承载的 QPS 直接翻倍。反过来,压测拉高 QPS 的过程中 RT 迟早上涨,上涨的拐点就是系统容量的信号。

三、峰值估算:Little's Law ​

排队论里的 Little's Law(利特尔法则)是上面两个公式的理论根基:

L = λ × W
系统内平均请求数 L = 到达速率 λ × 单请求平均停留时间 W

换个方向读就是 λ = L ÷ W,即 QPS = 并发数 ÷ RT。三个典型用法:

  1. 估容量:应用单机 200 个工作线程、平均 RT 50ms,则单机理论上限 QPS ≈ 200 ÷ 0.05 = 4000;
  2. 反推资源:目标峰值 QPS 10000、RT 预算 50ms。并发能力为 10000 × 0.05 = 500,据此定线程池、连接池和实例数;
  3. 定线程池:下游 RT 100ms、上游预期 QPS 200。则调用方需要 200 × 0.1 = 20 个并发线程,池子再留些余量。

注意 Little's Law 描述的是稳态平均。峰值还要乘集中系数(一般取日均的 3~10 倍,大促场景单独压测定)。实例数 = 峰值 QPS ÷ 单机安全 QPS(单机压测值再打折留水位,如 70%)。

四、压测口径 ​

报 QPS 数字前,先对齐口径,否则数字没有可比性:

  • 预热后统计:JIT 编译、缓存填充需要时间,冷启动前几十秒的数据偏低;
  • 压测时长要够:至少覆盖一次 Full GC 和定时任务周期,否则躲过了 GC 停顿的数字偏乐观;
  • 看拐点不只看均值:逐步加压,记录"QPS 上去时 P99 RT 的变化"。最大吞吐点(QPS 顶点)和 SLA 点(P99 达标的最高 QPS)往往不是一个数,对外承诺用后者;
  • 场景要真:读写比、数据分布、缓存命中率要贴近线上。压测请求全是同一参数会把缓存打满,QPS 虚高;压测流量没有真实用户的长尾特征,RT 偏乐观。

五、常见追问 ​

  • "你们系统 QPS 多少?"——标准答法要分三层:单机峰值 / 集群峰值、日均与峰值、核心接口与整体流量。混在一起说的数字没有意义;
  • "QPS 上不去先查什么?"——先看 RT 是否恶化(资源到顶了),再看得益于谁、受制于谁(下游、DB、锁、连接池排队);
  • "QPS 和 RT 哪个优先?"—— SLA 视角先保 RT(用户体验),容量视角通过扩容把两者同时抬上去。

延伸阅读:PV、GMV、ACK。

2026-10 扩充(原内容过薄)。