3. 并发用户数和 TPS 怎么理解
并发用户数和 TPS 是性能测试面试中最容易混淆的两个概念。很多同学会把在线用户数、注册用户数、JMeter 线程数、并发用户数混在一起，也会把 TPS 和 QPS 混用。面试官问这些概念，不是为了听定义，而是想看你是否能用它们设计真实压测场景。
简单说，并发用户数描述“有多少用户同时对系统施加压力”，TPS 描述“系统每秒处理多少业务事务”。两者有关联，但不是简单等价关系。
一、并发用户数是什么
并发用户数通常指同一时间正在对系统发起请求或保持业务操作压力的用户数量。
它不是：
- 注册用户数；
- 总用户数；
- 日活用户数；
- 在线用户数；
- 页面停留人数。
比如一个系统有 100 万注册用户，日活 10 万，高峰在线 1 万，但真正同一秒点击下单的可能只有几百人。
二、JMeter 线程数是不是并发用户数
JMeter 线程数可以近似看作虚拟用户数，但不完全等同于真实并发。
真实压力还受影响：
- 响应时间；
- 思考时间；
- 循环次数；
- ramp-up；
- 定时器；
- 脚本逻辑；
- 网络延迟。
100 个线程不一定每一秒都在同时请求接口。
三、TPS 是什么
TPS 是 Transactions Per Second，每秒事务数。
事务是业务动作，比如：
- 登录一次；
- 查询一次商品；
- 提交一次订单；
- 完成一次支付回调。
如果一个事务包含多个接口，TPS 是业务事务吞吐，不一定等于接口请求数。
四、QPS 是什么
QPS 是 Queries Per Second，每秒请求数或查询数。
在接口层面，一个业务事务可能对应多个请求。
例如一个下单事务包含：
- 查询商品；
- 计算优惠；
- 创建订单；
- 查询订单。
如果下单 TPS 是 100，那么接口 QPS 可能是 400 或更多。
五、并发用户数和 TPS 的关系
可以用一个简单公式理解：
TPS ≈ 并发用户数 / 平均响应时间
如果考虑思考时间：
TPS ≈ 并发用户数 / (响应时间 + 思考时间)
例如 100 个用户，每个事务平均耗时 1 秒，没有思考时间，理论 TPS 约 100。如果每次操作后思考 4 秒，则 TPS 约 20。
这只是估算，真实结果还受系统处理能力影响。
六、并发用户数怎么估算
可以从业务数据估算：
高峰小时请求量 / 3600 = 平均每秒请求量
再结合峰值系数、业务比例、用户操作频率估算。
例如高峰 1 小时有 36 万次查询请求，平均 QPS 是 100。如果峰值系数按 3 估算，峰值 QPS 约 300。
七、TPS 上不去说明什么
TPS 上不去可能原因：
- 系统达到瓶颈；
- 响应时间升高；
- 线程数不够；
- 压测机资源不足；
- 网络带宽不足；
- 数据库慢 SQL；
- 连接池耗尽；
- 应用线程池不足；
- 限流；
- 脚本有思考时间或阻塞。
不能只看 TPS，要结合资源指标判断。
八、响应时间和 TPS 的关系
当系统没有瓶颈时，增加并发可能提升 TPS。
当系统达到瓶颈后，继续增加并发，TPS 可能不再上升，响应时间和错误率反而上升。
这种拐点是性能测试分析重点。
九、常见误区
1. 注册用户数等于并发用户数
完全错误。注册用户只是总量，不代表同时访问。
2. 在线用户数等于并发用户数
在线用户可能只是登录状态，不一定正在发请求。
3. JMeter 线程数等于 TPS
线程数是虚拟用户数，TPS 是系统吞吐结果。
4. TPS 越高越好
TPS 要结合响应时间和错误率看。错误率很高的 TPS 没有意义。
十、面试回答模板
如果面试官问“并发用户数和 TPS 怎么理解”，可以这样回答：
并发用户数表示同一时间对系统施加压力的用户数量，不等于注册用户数或在线用户数。JMeter 线程数可以近似模拟虚拟用户，但真实并发还受响应时间、思考时间、循环和 ramp-up 影响。TPS 是每秒处理的业务事务数，比如每秒下单数或登录数；QPS 更偏接口请求数，一个业务事务可能包含多个接口，所以 TPS 和 QPS 不一定相等。两者关系可以粗略理解为 TPS 约等于并发用户数除以响应时间加思考时间。性能分析时要结合 TPS、响应时间和错误率一起看，不能单独看一个指标。
十一、练习清单
- 区分注册用户和并发用户；
- 区分在线用户和并发用户；
- 解释 JMeter 线程数；
- 解释 TPS；
- 解释 QPS；
- 用公式估算 TPS；
- 分析 TPS 上不去；
- 观察响应时间变化；
- 找性能拐点；
- 准备概念面试回答。
并发用户数和 TPS 是性能测试的基础。理解它们的关系，才能设计合理压测模型，而不是盲目加线程。
配套刷题：
