文章 04
并发用户、RPS、TPS 与延迟：正确理解系统负载
区分用户、请求与交易，并把 GA Realtime 转换为不过度解读的初步负载模型。
RPS
250
p95
780ms
TPS
38
示例场景
从系统使用者开始
一万用户并不等于一万并发请求
有些用户在阅读，有些在搜索，只有少数在同一秒保存。以总账号数设计会高估或低估需求，必须转换为并发、请求率与业务交易。
面向业务与一般用户的摘要
并发用户、RPS、TPS 与延迟：正确理解系统负载
并发用户是同一时段活跃的人，不是总账号数。
RPS 统计请求，TPS 统计有业务意义的交易。
吞吐量必须结合延迟、错误率与资源指标解读。
动态扩展说明
深入阅读前，先了解各阶段如何连接
选择阶段，查看发生了什么、需要检查哪些证据，以及一个决策如何影响下一阶段。
步骤 01 / 04
01 / 区分单位
用户、请求与交易是系统的不同视角
一笔交易可能调用多个 API，每个 API 又可能查询数据库多次。这些数字是分层的，仅有并发用户而没有行为模型，不足以规划容量。
需要检查的证据
- 并发用户：同一窗口内活跃的人
- RPS：每秒所有请求
- TPS：每秒业务交易
- 延迟：响应时间，包括 p50、p95、p99
深入说明
逐项说明如何应用于真实场景
每一部分都连接业务影响与 Tech Lead 需要检查的内容，包括示例、证据与限制。
01 / 区分单位
01用户、请求与交易是系统的不同视角
一笔交易可能调用多个 API，每个 API 又可能查询数据库多次。这些数字是分层的，仅有并发用户而没有行为模型，不足以规划容量。
- 并发用户：同一窗口内活跃的人
- RPS：每秒所有请求
- TPS：每秒业务交易
- 延迟：响应时间，包括 p50、p95、p99
- 错误率：失败请求比例
02 / 工作负载模型
02从行为出发，再计算 RPS
定义每个活跃用户的操作频率、每次操作的请求数与高峰倍数。这些参数应来自访问日志、分析或观察，而不是所有系统共用默认值。
计算示例
500 个并发用户
每位用户平均每 6 秒产生 1.5 个请求，并使用 2 倍高峰系数。
Base RPS = 500 × 1.5 ÷ 6 = 125; Peak RPS = 125 × 2 = 250250 RPS 是初始测试目标，并不证明生产系统已经能够承载。
03 / 从 GA 到服务器
03GA Realtime 是起点，不是直接并发数
GA 显示时间窗口内用户，服务器则每秒接收请求。转换需要活跃时长、页面行为、后台调用与实际交互比例，并与访问日志及服务器/数据库指标对照。
SPA 每次页面浏览可能调用多个 API，轮询与重试会使 RPS 高于可见操作。
04 / 局限
04相同 RPS 不代表相同资源消耗
缓存读取与大型报表请求的成本差异很大。判断容量前必须区分端点、负载、查询次数、外部依赖与缓存命中率。
行动前检查清单
定义活跃用户
确定关键操作
计算每次操作请求数
区分业务交易
依据数据确定高峰倍数
与真实日志对比