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

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

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

文章目录

  • 容量测试到底测什么？一次对话理清"同时在线"和"并发请求"
    • 一、起点：一个常见的判断
      • 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默认200200个并发请求就开始排队，跟内存无关
数据库连接池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、内存、线程数、GCCPU持续>80%、频繁Full GC
Web容器活跃线程数、请求队列长度线程满、请求排队超时
连接池活跃连接数、等待连接数连接耗尽、请求等待
数据库活跃会话数、锁等待、慢SQL锁冲突、SQL变慢
网络带宽、连接数、丢包响应时间飙升

5.3 常见场景

场景最先断的环节解法方向
政务OA数据库连接池（默认太小）调大连接池上限
查询密集型数据库慢SQL加索引、优化SQL、读写分离
计算密集型应用服务器CPU加机器、异步化
秒杀类数据库行锁队列削峰、缓存

六、总结

6.1 三个结论

  1. 同时在线和并发请求是两个概念——在线用户的内存开销确实很小（session或JWT都不到1KB），可以忽略
  2. 但在线人数越高，并发越高——两者通过用户活跃率关联，不能脱离用户行为谈容量
  3. 瓶颈永远在并发请求层——线程池、连接池、CPU、数据库，这些才是容量上限的真正决定因素

6.2 一句话

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