性能测试中常说的并发、在线用户数的1:10比例从何而来？

在性能测试行业里，有一个流传甚广的“江湖规矩”：
系统如果需要支撑 100 人同时在线，做 10 个并发压测就够了；如果要支撑 200 人在线，20 个并发也就齐活了。

也就是我们常说的 1:10 的并发在线比。

刚入行测试的时候，这句话听过无数次，但总觉得心里发虚：这比例是拍脑袋定的吗？要是客户非得咬死“200人在线就要200并发一起上”，我们该怎么反驳？

直到有一天，我们把压测数据丢进 Little 定律（利特尔法则） 里一算，才发现这个比例不仅是真的，而且藏着严密的数学闭环。

一、 概念分清：谁在“在线”，谁在“并发”？

在解释为什么是 1:10 之前，我们得先帮客户（甚至部分开发）理清两个极其容易混淆的概念：

1. 在线用户数（Online Users）：
   指的是“挂在系统上”的人。比如 200 个员工登录了企业 OA，或者 200 个用户打开了 App 没关闭。他们保持着登录态或心跳连接，但此时此刻并不一定在操作。
2. 并发用户数（Concurrent Users）：
   指的是在同一精确时间点，实实在在地向服务器发送请求、点击提交、查询数据的人。

人类不是机器，100 个在线用户在宏观的一分钟里，大家的动作是错开的：有人在看页面（思考时间），有人在填表单，有人在喝水。真正在同一毫秒向服务器发起冲击的，永远只是少数人。

行业历史统计和日常业务分析表明，在常规业务系统的访问高峰期，同时段处于活跃操作状态的用户数，通常占在线总人数的 5% 到 15% 之间。“1:10”（即 10%）恰好取了一个最稳健的中间值。

二、 实践出真知：用 JMeter 压测数据来验证

光有经验比例还不够，我们在实际做压测时，怎么用硬核数据说服自己和客户？

来看一个真实的 JMeter 聚合报告（Aggregate Report）数据：

• 吞吐量（Throughput）： 61.5 /sec（系统每秒处理 61.5 个请求）
• 平均响应时间（Average）： 322 ms（即 0.322 秒）
• 我们在 JMeter 中设置的并发线程数： 20 线程

此时，排队论中最具统治力的公式登场了——Little 定律：
C = λ x R
(并发数 = 吞吐量 × 平均响应时间)

把数据代进去：
C = 61.5(吞吐量) x 0.322（平均响应时间）= 19.8{并发人数}

结果完美吻合： 我们在 JMeter 里设置的 20 并发，通过 Little 定律反算出来的瞬时并发处理量也是 20！而按照 1:10 的比例换算，这组 20 并发稳稳承载的业务体量，正是 200 人的在线规模。

三、 为什么 Little 定律算得这么准？

有些朋友可能会感叹：这公式怎么这么“神”？

其实，Little 定律不是经验猜想，而是一个经过严格数学证明的绝对恒等式。

你可以把它想象成物理学里的质量守恒，或者 S = v x t（路程 = 速度 × 时间）：

• λ（吞吐量）就像是流进水池的水速。
• R（响应时间）就像是一滴水在池子里停留的平均时间。
• C（并发数）就是任何一个瞬间，水池里正存留的水的总量。

最神奇的是，Little 定律对系统的底层技术“完全盲目”——无论你的后端是 Java 还是 Go，数据库是 MySQL 还是 Redis，它都不管。只要系统在一段时间内达到了“稳态”（没有发生雪崩、死锁或严重阻塞），这个数学关系就必然成立。

四、 面对客户的“灵魂拷问”，我们该怎么说？

在实际工作中，最头疼的往往不是技术本身，而是跟对性能指标有误解的客户沟通。

如果客户提出：“我们的业务指标是 200 人在线，为什么你们只做 20 并发？是不是想偷工减料？”

你可以用这套组合拳理直气壮地回应：

1. 区分概念： “200 人在线不等于 200 人同时按回车。如果要求 200 个物理并发同时点，相当于系统在同一瞬间要支撑 2000 人规模的在线洪峰。”
2. 科学依据： “根据排队论和行业通用的 1:10 活跃比，200 人在线在高峰期的真实活跃并发就是 20 左右。”
3. 闭环验证： “我们通过 JMeter 压测和 Little 定律（C = λ x R）进行了实测验证，20 并发下系统吞吐量和响应时间完全平稳。这既保证了真实业务场景的真实压力，又避免了盲目堆砌硬件带来的资源浪费。”

结语

性能测试不只是简单的“点一下 Start 按钮”，更是业务逻辑与数学原理的交织。下次再遇到客户问起并发与在线的关系，不妨自信地告诉他：“20 并发，足够撑起你 200 人的业务江山了！”