容量测试到底测什么一次对话理清同时在线和并发请求和同事讨论容量测试发现很多人把同时在线和并发请求搅在一起。这篇把这段对话记录下来帮你看清容量的本质。文章目录容量测试到底测什么一次对话理清同时在线和并发请求一、起点一个常见的判断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。用户登录后拿到一个tokentoken存在客户端浏览器localStorage或Cookie。服务器不存任何东西。用户登录 → 服务器签发JWT → 返回给客户端 ↓ 用户后续请求 → 带上JWT → 服务器验签 → 处理请求 ↓ 请求结束 → 服务器什么都不留用户拿不到token时在浏览页面、填表单、看数据——这段时间对服务器来说这个用户不存在。服务器不给他分配线程、不分配连接、不分配内存。所以同时在线10万人和100人对服务器来说没区别——因为大部分在线用户此刻没有在发请求。2.2 那有session的系统呢有同事会说我们的系统用Tomcat的HttpSession每个用户在服务端存一份session这不就占内存了吗算一笔账。一个session里实际存什么数据大小估算用户信息id、姓名、账号~200字节机构信息id、名称~100字节角色列表几个角色ID~50字节权限标识如果是角色ID而非逐个权限~100字节合计不到1KB1000人在线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默认maxThreads200 → 不够要调大 数据库连接池默认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 GCWeb容器活跃线程数、请求队列长度线程满、请求排队超时连接池活跃连接数、等待连接数连接耗尽、请求等待数据库活跃会话数、锁等待、慢SQL锁冲突、SQL变慢网络带宽、连接数、丢包响应时间飙升5.3 常见场景场景最先断的环节解法方向政务OA数据库连接池默认太小调大连接池上限查询密集型数据库慢SQL加索引、优化SQL、读写分离计算密集型应用服务器CPU加机器、异步化秒杀类数据库行锁队列削峰、缓存六、总结6.1 三个结论同时在线和并发请求是两个概念——在线用户的内存开销确实很小session或JWT都不到1KB可以忽略但在线人数越高并发越高——两者通过用户活跃率关联不能脱离用户行为谈容量瓶颈永远在并发请求层——线程池、连接池、CPU、数据库这些才是容量上限的真正决定因素6.2 一句话容量测试不是测能挂多少用户是测这些用户一起点的时候哪个环节先断。