容量测试到底测什么——一次对话理清同时在线和并发请求

容量测试到底测什么？一次对话理清"同时在线"和"并发请求"

和同事讨论容量测试，发现很多人把"同时在线"和"并发请求"搅在一起。这篇把这段对话记录下来，帮你看清容量的本质。

文章目录

• 容量测试到底测什么？一次对话理清"同时在线"和"并发请求"
• • 一、起点：一个常见的判断
  • • 1.1 同事的初始判断
    • 1.2 先搞清两个概念
  • 二、如果只看"同时在线"，容量确实可以非常大
  • • 2.1 无状态架构：在线用户几乎不花钱
    • 2.2 那有session的系统呢？
  • 三、但是：在线人数越高，并发请求越高
  • • 3.1 统计关系
    • 3.2 容量和并发是一个连续光谱
    • 3.3 一个实际例子
  • 四、并发请求的真正瓶颈在哪
  • • 4.1 一个请求进来的真实开销
    • 4.2 瓶颈清单
    • 4.3 一个并发请求的开销
  • 五、容量测试到底测什么
  • • 5.1 测的是第一个被打破的瓶颈
    • 5.2 各层监控指标
    • 5.3 常见场景
  • 六、总结
  • • 6.1 三个结论
    • 6.2 一句话

一、起点：一个常见的判断

1.1 同事的初始判断

同事做政务系统，要搞容量测试。他的判断是：

容量测试应该只和服务端内存有关系吧？session或者jwt也占用不了多少内存，容量应该可以非常大。

乍一看没毛病——一个JWT字符串几百字节，一个session对象也就存点用户信息，内存开销确实不大。那同时在线几万人，内存也吃不了多少。容量瓶颈不该是内存吧？

但这个判断有一个隐藏的概念混淆。

1.2 先搞清两个概念

这是两个完全不同的东西。 很多开发者嘴上说着"系统容量要支撑一万用户"，实际上担心的是"一万用户同时点按钮服务器扛不扛得住"——前者是容量问题，后者是并发问题。

二、如果只看"同时在线"，容量确实可以非常大

2.1 无状态架构：在线用户几乎不花钱

现在的系统基本都用JWT。用户登录后拿到一个token，token存在客户端（浏览器localStorage或Cookie）。服务器不存任何东西。

用户登录 → 服务器签发JWT → 返回给客户端
↓
用户后续请求 → 带上JWT → 服务器验签 → 处理请求
↓
请求结束 → 服务器什么都不留

用户拿不到token时在浏览页面、填表单、看数据——这段时间对服务器来说，这个用户不存在。服务器不给他分配线程、不分配连接、不分配内存。

所以：同时在线10万人和100人，对服务器来说没区别——因为大部分在线用户此刻没有在发请求。

2.2 那有session的系统呢？

有同事会说：我们的系统用Tomcat的HttpSession，每个用户在服务端存一份session，这不就占内存了吗？

算一笔账。一个session里实际存什么？

1000人在线，session内存不到1MB。10000人在线，也就几MB。跟服务器动辄几个G的内存比，完全可以忽略。

所以无论session还是JWT，在线人数本身都不是瓶颈。 同事最初的判断方向是对的——容量确实可以非常大。

三、但是：在线人数越高，并发请求越高

3.1 统计关系

到这里同事说：那容量不是问题啊，随便扛。

但这里有个统计关系：一个系统，在相关条件不变化，同时在线用户数量越多，并发会越高。

100个人在线，同一时刻可能有5个人在点按钮。10000个人在线，同一时刻可能有500个人在点。在线人数上去了，并发请求自然跟着上去。

并发请求数 ≈ 同时在线人数 × 用户活跃率

用户活跃率 = 用户在单位时间内发起请求的概率

不同系统的用户活跃率差异极大：

所以不能脱离用户行为谈容量。容量不是孤立的"能挂多少在线用户"，而是"这些在线用户产生的高并发，服务器扛不扛得住"。

3.2 容量和并发是一个连续光谱

容量测试 并发测试
（能挂多少在线用户） （在线用户产生的高并发扛不扛得住）
←————————————————————————————→
统计桥梁：用户活跃率

两者不是对立的，是同一条链路上的两端。容量测试关注左端——系统能容纳多少在线用户。并发测试关注右端——这些用户产生的请求高峰能不能扛。中间的桥梁就是用户行为模式。

3.3 一个实际例子

某政务系统，预期5000人同时在线。做容量测试时要算的不是"5000个session占多少内存"，而是：

5000人在线
× 用户活跃率（假设10%在同时操作）
= 500个并发请求
↓
Tomcat默认maxThreads=200 → 不够，要调大
数据库连接池默认20 → 远远不够，要调大
↓
这才是容量测试要回答的问题

瓶颈不在"5000人在线"，瓶颈在"5000人产生的500个并发请求"。

四、并发请求的真正瓶颈在哪

4.1 一个请求进来的真实开销

既然瓶颈在并发请求，那一个请求到底吃服务器什么资源？

HTTP请求到达
↓
Tomcat线程池分配线程（maxThreads，默认200）
↓
从连接池拿数据库连接（默认8~20个）
↓
执行业务逻辑（CPU计算、JWT验签、序列化）
↓
查数据库（可能等待锁、等待IO）
↓
返回响应
↓
释放线程和连接

每一环都可能先于内存成为瓶颈。

4.2 瓶颈清单

4.3 一个并发请求的开销

不要把"一个用户在线"和"一个请求处理"搞混：

1000个并发请求，光线程栈就吃掉1GB内存。 而且线程切换的CPU开销比内存更致命。

所以"容量可以非常大"这句话对了一半——在线用户的容量确实很大，但他们产生的并发请求打到的瓶颈，不在内存，在别的地方。

五、容量测试到底测什么

5.1 测的是第一个被打破的瓶颈

容量测试不是"应用服务器内存能挂多少session"，而是从用户请求到数据库返回，这条链路上哪个环节最先断。

不断加压，观察哪个指标先异常：

逐渐增加在线用户数（或直接加并发请求）
↓
监控每一层的指标
↓
第一个先撑不住的环节 = 系统的真实容量上限

5.2 各层监控指标

5.3 常见场景

六、总结

6.1 三个结论

6.2 一句话

容量测试不是测"能挂多少用户"，是测"这些用户一起点的时候，哪个环节先断"。