一、核心要素定义与概念辨析
在性能测试与高并发架构设计中，很多工程师容易混淆 并发用户数、QPS 与 TPS 的概念。理清这三者的边界是设计合理压测场景的前提。
1. QPS（Queries Per Second）
- 定义：每秒钟系统处理的请求数量（以网络 Request 为原子单位）。
- 场景：通常用于衡量底层接口、反向代理（Nginx）或数据库的瞬时网络吞吐能力。
2. TPS（Transactions Per Second）
- 定义：每秒钟系统完成的事务数量。
- 场景：以端到端业务场景为度量单位。一个业务事务可能由多个底层 HTTP 请求组合而成（例如：“用户下单”事务包含了查库存、创建订单、扣减余额 3 个接口请求）。
3. 并发数（Concurrency）
- 定义：系统在同一时刻正在并发处理的请求/事务总量。
- 区别：
- 广义并发用户数：在线登录系统并浏览页面的用户总数；
- 狭义并发用户数（并发度）：在同一毫秒内真正正在向服务端发送请求的用户数量。
二、利特尔法则（Little's Law）核心公式
在稳定运行的系统中，吞吐量、并发数与响应时间满足利特尔法则：
$$\text{并发数} = \text{TPS} \times \text{平均响应时间}$$
或者变形为：
$$\text{TPS} = \frac{\text{并发数}}{\text{平均响应时间}}$$
典型计算实例：
假设某企业早高峰考勤打卡系统：
- 共有 1200 名员工在早上 07:30 ~ 08:00（30 分钟 = 1800 秒）内完成打卡；
- 系统单次打卡接口的平均响应时间为 0.5 秒；
- 业务平均 TPS = $1200 \div 1800 \approx 0.67 \text{ TPS}$；
- 平均并发数 = $0.67 \times 0.5 \approx 0.34$。 若出现高峰拥堵，80% 的人集中在最后 5 分钟打卡，则峰值 TPS 需重新估算：
- 峰值 TPS = $(1200 \times 0.8) \div (5 \times 60) = 960 \div 300 = 3.2 \text{ TPS}$。
三、系统性能的三阶段“拐点模型”
随着并发压力持续增加，系统的吞吐量与响应时间并非呈线性变化，而是表现为典型的三阶段拐点曲线：
text
TPS / 响应时间
▲
│ [最大吞吐量拐点]
│ ┌──────────┐
│ / \ [超负荷崩溃区]
│ [轻负载区] / [最佳负载区] \ (TPS 急剧下跌，超时激增)
│ (线性增长) / \
│ / \
│ / \
└─────────────/───────────────────────\──────► 并发用户数1. 轻负载区（Light Load Zone）
- 特征：并发用户数较少，系统资源（CPU、内存、I/O）处于低负荷状态。
- 表现：TPS 随并发数增加呈近似线性增长，平均响应时间保持在极低基线。
2. 最佳性能点与平原区（Heavy Load Zone）
- 特征：并发持续增加，系统某项关键资源（如数据库连接池、CPU 核心使用率）达到瓶颈。
- 表现：TPS 增长放缓并维持在峰值平台期，响应时间开始显著拉长。此时的并发数通常为系统最佳并发承载量。
3. 崩溃区（Buckle Zone）
- 特征：并发数继续盲目增加，超过系统排队与线程池上限。
- 表现：频繁的线程上下文切换、内存垃圾回收停顿和连接超时导致系统有效吞吐量（TPS）断崖式下跌，响应时间呈指数级恶化，最终引发服务雪崩。
四、生产容量规划：二八法则推算法
在缺乏历史精细压测数据的情况下，业界通常使用“二八原则”对日常 PV 预估系统所需承载的峰值 TPS：
$$\text{峰值 TPS} = \frac{\text{全天总 PV} \times 80%}{\text{全天运行时间（秒）} \times 20%}$$
举例：
假设某内部业务系统预计全天产生 500 万次页面访问（PV）：
- 有效访问时间集中在 8 小时内（$8 \times 3600 = 28,800$ 秒）；
- 80% 的流量（400 万 PV）发生在 20% 的时间段（5760 秒）内；
- 预估峰值 TPS = $4,000,000 \div 5,760 \approx 694 \text{ TPS}$。
- 在容量规划时，结合 2~3 倍的容灾冗余系数，该系统在上线前应按照 $1500 \sim 2000 \text{ TPS}$ 作为目标基线进行压测验证。