两套配置相近的系统，在线人数上限可能差很多：用户操作频率、请求链路和共享服务都能改变结果。要做在线人数承载能力测算，关键不是比较机器参数，而是确定目标场景下的请求量，并找出最先触及限制的环节。
先把“在线人数”换成可测的负载
在线人数通常指已登录或保持会话的用户，但其中有人持续操作，有人长时间不动。测算时应另外定义“活跃用户”，并统计其在代表性时段内产生的请求数。举例说，若每名活跃用户平均每秒发出0.08个请求，1万人对应约800个请求每秒；这只是演算假设，实际值要由业务日志或负载测试取得。
还要区分平均请求量与突发请求量。页面刷新、定时同步或集中提交可能让短时峰值显著高于平均值。测试场景应覆盖常见操作路径，并记录请求速率、响应时间分位数、错误比例和资源使用情况，而不是只看某一时刻的总人数。
用服务目标找出最先到顶的环节
对每个关键环节，测出在响应时间和错误率仍符合要求时，可以稳定处理的请求速率。应用服务、数据存储、缓存、消息处理及第三方接口都可能成为瓶颈。系统整体容量受最小值约束：如果应用能处理较多请求，但数据库查询或外部接口先达到上限，继续增加应用实例并不会等比例提高承载量。
对请求型负载，可用以下估算：可用请求能力 ÷ 单个活跃用户平均请求率 = 可承载活跃用户数。可用请求能力不应直接取压测瞬间的最高值，而应在满足延迟、错误率等服务目标的稳定区间内确定，并预留余量。在线人数承载能力测算因此必须同时说明请求率、服务目标和测试条件。
按步骤完成一次估算
- 定义口径：明确统计的是登录人数、连接数还是活跃人数，并选定需要保障的响应时间和错误率目标。
- 采集真实负载：从访问日志、应用指标或业务事件中统计请求类型和频次。分别记录普通操作与高峰时段，避免用整日平均值代替峰值。
- 逐级压测：逐步增加并发，观察请求速率、延迟变化、超时和队列积压。测试时固定软件版本、数据规模及请求组成，便于比较。
- 定位瓶颈：检查请求链路中每个依赖的处理能力与排队情况。若某一环节先达到服务目标边界，应先优化该环节，再重新测试整条链路。
- 换算并复核：以最窄环节的稳定能力除以单个活跃用户请求率，再乘以预留比例。预留比例可先按约70%至80%做规划起点，具体取值需依据负载波动、故障恢复方式和业务容忍度调整。
示例：为什么单看应用吞吐会高估
假设一组压测中，满足既定响应目标时应用可处理1200个请求每秒；每名活跃用户平均产生0.08个请求每秒，按75%的规划利用率计算，应用侧估算约为11250名活跃用户。但若共享数据服务稳定上限只有900个请求每秒，则同样口径下可用能力约为675个请求每秒，折算约8430名活跃用户。这个例子仅用于展示算法，数值不是通用基准，也不能代替具体系统的测试。
换算得到的通常是活跃用户数，不等于同时登录人数。若登录用户中只有一部分在同一时段操作，应依据实测活跃比例另行换算；比例会随产品流程和时段变化，不宜凭经验固定。完成在线人数承载能力测算后，还应在更大数据量、突发流量和依赖变慢等条件下复测。
常见问题
只用并发连接数能估算人数吗？
不能单独使用。连接数反映会话或连接占用，不说明每个用户的请求频率和后端处理成本。
测试最高请求速率可以直接作为上线容量吗？
不建议。应选取仍满足延迟与错误率目标的稳定区间，并留出应对波动的余量。
用户行为变化后要重新测算吗？
需要。请求频率、操作路径或依赖服务改变，都可能改变瓶颈。应更新负载模型并复测。
可靠的在线人数承载能力测算，最终要落到可复现的负载模型、明确的服务目标和最窄环节的稳定容量上，而不是单机配置表上的数字。