容量测试到底测什么——一次对话理清同时在线和并发请求
容量测试到底测什么？一次对话理清"同时在线"和"并发请求"
和同事讨论容量测试，发现很多人把"同时在线"和"并发请求"搅在一起。这篇把这段对话记录下来，帮你看清容量的本质。
文章目录
- 容量测试到底测什么？一次对话理清"同时在线"和"并发请求"
- 一、起点：一个常见的判断
- 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 先搞清两个概念
| 同时在线（容量） | 并发请求 | |
|---|---|---|
| 含义 | 多少用户登录着、在用系统 | 服务器同一时刻在处理多少请求 |
| 对服务器的直接压力 | JWT几乎为零，session很小 | 每个请求吃线程+连接+CPU |
| 瓶颈在哪 | 几乎没有 | 线程池/连接池/CPU/数据库 |
这是两个完全不同的东西。很多开发者嘴上说着"系统容量要支撑一万用户"，实际上担心的是"一万用户同时点按钮服务器扛不扛得住"——前者是容量问题，后者是并发问题。
二、如果只看"同时在线"，容量确实可以非常大
2.1 无状态架构：在线用户几乎不花钱
现在的系统基本都用JWT。用户登录后拿到一个token，token存在客户端（浏览器localStorage或Cookie）。服务器不存任何东西。
用户登录 → 服务器签发JWT → 返回给客户端 ↓ 用户后续请求 → 带上JWT → 服务器验签 → 处理请求 ↓ 请求结束 → 服务器什么都不留用户拿不到token时在浏览页面、填表单、看数据——这段时间对服务器来说，这个用户不存在。服务器不给他分配线程、不分配连接、不分配内存。
所以：同时在线10万人和100人，对服务器来说没区别——因为大部分在线用户此刻没有在发请求。
2.2 那有session的系统呢？
有同事会说：我们的系统用Tomcat的HttpSession，每个用户在服务端存一份session，这不就占内存了吗？
算一笔账。一个session里实际存什么？
| 数据 | 大小估算 |
|---|---|
| 用户信息（id、姓名、账号） | ~200字节 |
| 机构信息（id、名称） | ~100字节 |
| 角色列表（几个角色ID） | ~50字节 |
| 权限标识（如果是角色ID而非逐个权限） | ~100字节 |
| 合计 | 不到1KB |
1000人在线，session内存不到1MB。10000人在线，也就几MB。跟服务器动辄几个G的内存比，完全可以忽略。
所以无论session还是JWT，在线人数本身都不是瓶颈。同事最初的判断方向是对的——容量确实可以非常大。
三、但是：在线人数越高，并发请求越高
3.1 统计关系
到这里同事说：那容量不是问题啊，随便扛。
但这里有个统计关系：一个系统，在相关条件不变化，同时在线用户数量越多，并发会越高。
100个人在线，同一时刻可能有5个人在点按钮。10000个人在线，同一时刻可能有500个人在点。在线人数上去了，并发请求自然跟着上去。
并发请求数 ≈ 同时在线人数 × 用户活跃率 用户活跃率 = 用户在单位时间内发起请求的概率不同系统的用户活跃率差异极大：
| 系统类型 | 用户活跃率 | 说明 |
|---|---|---|
| 政务OA | 低 | 大部分时间在看页面、填表，几秒点一次 |
| 电商日常 | 中 | 浏览、加购物车、搜索 |
| 电商秒杀 | 极高 | 所有人同时点抢购按钮 |
| 即时通讯 | 高 | 收发消息、状态同步，几乎一直在请求 |
所以不能脱离用户行为谈容量。容量不是孤立的"能挂多少在线用户"，而是"这些在线用户产生的高并发，服务器扛不扛得住"。
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 瓶颈清单
| 瓶颈 | 默认上限 | 说明 |
|---|---|---|
| 线程池 | Tomcat默认200 | 200个并发请求就开始排队，跟内存无关 |
| 数据库连接池 | Druid/HikariCP默认8~20 | 拿不到连接的请求要么等要么超时 |
| CPU | 看核数 | JWT验签、序列化、加解密、业务计算 |
| 数据库本身 | 几百~上千并发 | 锁竞争、慢查询，数据库比应用服务器先扛不住 |
| 内存 | 看配置 | session/JWT确实占不了多少 |
4.3 一个并发请求的开销
不要把"一个用户在线"和"一个请求处理"搞混：
| 资源 | 一个在线用户（空闲） | 一个正在处理的请求 |
|---|---|---|
| 线程 | 无 | 一个线程（栈空间512KB~1MB） |
| 数据库连接 | 无 | 一个连接（连接对象+会话状态） |
| 内存 | session/JWT ~1KB | 结果集、序列化缓冲、临时对象 |
| CPU | 无 | JWT验签、业务计算、序列化 |
1000个并发请求，光线程栈就吃掉1GB内存。而且线程切换的CPU开销比内存更致命。
所以"容量可以非常大"这句话对了一半——在线用户的容量确实很大，但他们产生的并发请求打到的瓶颈，不在内存，在别的地方。
五、容量测试到底测什么
5.1 测的是第一个被打破的瓶颈
容量测试不是"应用服务器内存能挂多少session"，而是从用户请求到数据库返回，这条链路上哪个环节最先断。
不断加压，观察哪个指标先异常：
逐渐增加在线用户数（或直接加并发请求） ↓ 监控每一层的指标 ↓ 第一个先撑不住的环节 = 系统的真实容量上限5.2 各层监控指标
| 层次 | 监控什么 | 异常表现 |
|---|---|---|
| 应用服务器 | CPU、内存、线程数、GC | CPU持续>80%、频繁Full GC |
| Web容器 | 活跃线程数、请求队列长度 | 线程满、请求排队超时 |
| 连接池 | 活跃连接数、等待连接数 | 连接耗尽、请求等待 |
| 数据库 | 活跃会话数、锁等待、慢SQL | 锁冲突、SQL变慢 |
| 网络 | 带宽、连接数、丢包 | 响应时间飙升 |
5.3 常见场景
| 场景 | 最先断的环节 | 解法方向 |
|---|---|---|
| 政务OA | 数据库连接池（默认太小） | 调大连接池上限 |
| 查询密集型 | 数据库慢SQL | 加索引、优化SQL、读写分离 |
| 计算密集型 | 应用服务器CPU | 加机器、异步化 |
| 秒杀类 | 数据库行锁 | 队列削峰、缓存 |
六、总结
6.1 三个结论
- 同时在线和并发请求是两个概念——在线用户的内存开销确实很小（session或JWT都不到1KB），可以忽略
- 但在线人数越高，并发越高——两者通过用户活跃率关联，不能脱离用户行为谈容量
- 瓶颈永远在并发请求层——线程池、连接池、CPU、数据库，这些才是容量上限的真正决定因素
6.2 一句话
容量测试不是测"能挂多少用户"，是测"这些用户一起点的时候，哪个环节先断"。