QPS（每秒查询数）指标
1. 什么是QPS？
QPS，全称是Queries Per Second，每秒查询数。说白了，就是你的系统在一秒钟内能处理多少个请求。我刚开始做压测时，老把QPS和TPS搞混，后来发现一个简单的区分方法：QPS侧重查询场景，TPS侧重事务场景。但在接口压测里，这两个概念经常混着用，大家心里有数就行。
核心定义：单位时间内成功处理的请求数量。注意是「成功处理」，不是「收到请求」。那些被拒绝的、超时的、返回5xx的，统统不算。
2. QPS的计算方式
计算公式其实很简单：
QPS = 总请求数 / 总耗时（秒）举个例子：1秒内处理了500个请求，QPS就是500。
但在真实压测中，我更习惯用另一种方式算：
平均响应时间（RT） = 总耗时 / 成功请求数
QPS = 1000ms / 平均响应时间（ms）举个例子，假设接口平均响应时间是20ms：
QPS = 1000 / 20 = 50这意味着单线程每秒能处理50个请求。如果开10个线程并发，理论QPS就是500。但理想很丰满，现实很骨感，线程多了会有上下文切换开销，实际值往往低于理论值。
3. 峰值QPS vs 平均QPS
这两个概念搞不清楚，压测报告基本等于白做。我见过不少新人，拿着平均QPS当系统容量上限，结果上线就被打爆。
| 指标 | 定义 | 计算方式 | 用途 |
|---|---|---|---|
| 平均QPS | 一段时间内的平均处理能力 | 总请求数 / 总时长 | 评估系统日常负载 |
| 峰值QPS | 某个瞬间的最高处理能力 | 1秒内的最大请求数 | 确定系统上限 |
为什么说平均QPS容易误导人？你想想看，线上流量从来不是均匀的。白天可能每分钟5000请求，凌晨可能只有500。平均下来看还行，但高峰期可能就把系统打垮了。
怎么确定峰值QPS？我的做法是：
- 先小并发压测，逐步增加线程数
- 记录每个线程数下的QPS
- 找到QPS不再增长的那个点——那就是峰值QPS
- 系统容量 = 峰值QPS × 0.7（安全系数）
打个比方，如果系统峰值QPS是2000，那我建议承载上限设在1400左右。留30%的缓冲空间，应对突发流量。
4. QPS与线程池配置的关系
做压测的人最常问的就是：「线程池设多大合适？」这个问题，得先搞懂QPS和线程池的关系。
核心公式是这样的：
QPS = 线程数 / 平均响应时间从这个公式能看出两个关键点：
- 线程数越多，QPS不一定越高。因为线程多了，CPU忙着切换上下文，真正干活的时间反而少了
- 响应时间越短，QPS越高。哪怕线程数不变，优化代码让接口快10ms，QPS可能翻倍
我一般用这个思路来配置线程池：
| 场景 | 核心线程数 | 最大线程数 | 队列容量 | 说明 |
|---|---|---|---|---|
| CPU密集型 | CPU核数 + 1 | CPU核数 × 2 | 50～100 | 计算操作多，线程多了反而慢 |
| IO密集型 | CPU核数 × 2 | CPU核数 × 4 | 100～500 | 等待IO时线程可以切换 |
| 混合型 | CPU核数 × 2 | CPU核数 × 3 | 200～300 | 根据实际压测调整 |
但这只是参考值。真正靠谱的做法是压测验证。我通常的做法是：
- 从最小线程数开始（比如4个）
- 每次增加2个线程，记录QPS变化
- 找到QPS拐点——就是线程再增加，QPS不再明显增长的那个点
- 把核心线程数设在这个拐点附近
举个例子，我之前测过一个用户服务：
- 4个线程时，QPS = 400
- 8个线程时，QPS = 750
- 12个线程时，QPS = 880
- 16个线程时，QPS = 900
- 20个线程时，QPS = 890（开始下降）
你看，12个线程时QPS已经接近峰值了。再多加线程，CPU忙着切换线程上下文，QPS反而降了。所以我把核心线程数设在12，最大线程数设在16作为缓冲。
通过这张图，你能看到QPS不是孤立存在的。它跟定义、计算方式、平均和峰值、以及线程池配置，全串在一起。做压测时，这几块内容得一条线捋清楚，缺一个都不行。