压测不只是加并发：我们模拟真实用户行为后，发现了隐藏瓶颈

在性能测试领域一个根深蒂固的误解是压测就是使劲加线程数看系统什么时候崩。很多团队用 JMeter 起 500 个并发照着接口列表跑一圈看到 TPS 平稳、响应时间没超过 300ms就觉得万事大吉。可一旦上线流量还没达到测试峰值的一半系统就开始大面积超时、数据库 CPU 打满、连接池耗尽。问题出在哪里答案很明确——你压的不是真实用户而是一群机械重复的“机器人”。真正的性能瓶颈只有在模拟出有血有肉的用户行为之后才会暴露出来。一、固定并发下的“虚假安全感”传统固定并发压测之所以容易制造出“性能良好”的假象根本原因在于它剥离了业务上下文的复杂性。假设我们设置 500 个线程持续循环调用下单接口每个请求间隔 0 秒这本质上是在进行拒绝服务攻击式的连续重压。然而真实用户的操作不是这样的。他们会在首页思考、会浏览详情、会犹豫比对、还会因为网络抖动重试。一个完整的电商下单流程用户会话时长往往在 30 秒到 90 秒之间其中真正与后端发生密集交互的只有 10 秒左右其余时间都在消耗连接、保持会话、执行低频率的状态轮询。这种差异造成了两大后果一是压力模型与线上流量完全错位。固定并发只考验了系统在恒定吞吐量下的稳态表现而真实流量是阶梯式涌来的——大促开始的前 5 分钟活动状态轮询每秒可能只有几百次但秒杀按钮按下的那一秒瞬间会涌入数万笔提交请求。二是关键的系统资源消耗路径被掩盖。例如数据库连接泄漏在低并发、长运行时间下表现正常但当并发数随时间缓慢攀升时连接池会逐渐膨胀直至耗尽缓存穿透也是如此突发流量会被缓存层瞬间阻挡但持续、缓慢增长的穿透性查询会逐步击穿缓存最终压垮数据库。我们曾经对一个促销系统做过固定 2000 并发的压测聚合报告中 90% 响应时间仅 178ms错误率为 0。然而在生产预演中当真实用户从 200 一路涨到 8000 时整个系统在 15 分钟后就彻底失联。事后复盘才发现真实用户在秒杀前大量轮询活动状态这些相对廉价的读请求持续占用了 Tomcat 线程池的绝大部分资源导致关键的秒杀提交请求迟迟得不到处理线程池的等待队列不断积压最终系统因“雪崩”效应瘫痪。这个教训告诉我们压力测试的精度不取决于并发数有多高而取决于用户行为链路有多真。二、从日志到脚本构建高保真用户模型要让压测真正有效必须将用户行为从“一堆数字”还原成“一群有行为逻辑的人”。我们的做法是从产品埋点日志和 Nginx 访问记录中提取用户行为画像建立包含多阶段、多分支、带随机延迟的事务型脚本。具体到一次秒杀压测我们分析了前 10 分钟的真实用户路径并按照比例建模首页轮询用户占 65%他们每隔数秒向/api/activity/status发一次 GET 请求采用指数退避策略首次间隔 1 秒第二次 2 秒第三次 4 秒直到活动状态变为“已开始”。这部分请求虽然是读操作但会持续消耗 HTTP 连接和数据库连接。浏览型用户占 22%进入商品详情页后平均停留 18.7 秒随后可能加入购物车或退出。他们的请求序列是随机的且包含较长的 Think Time。购买冲动型用户占 8%在活动开始瞬间立即发起秒杀提交经历防重 token 生成、库存预校验、最终下单这一链路是事务性的对数据库写操作有强依赖。结果轮询用户占 5%提交后持续查询秒杀结果直至超时。在 JMeter 脚本实现上我们摒弃了简单的循环请求改用Transaction Controller搭配If Controller、JSR223 Timer和参数化完整复现了以上四类用户的行为逻辑。例如轮询脚本使用While Controller不断检查活动状态状态值由前置 JSON 提取器获取每次轮询后通过Groovy脚本计算下一次休眠时间只有当响应体中status字段变为started时才跳出循环并标记“可提交”状态。秒杀提交模块则做到完全真实先从用户上下文中取出 token、活动 ID、商品 ID并携带从页面元素计算出的_sign参数所有参数化数据来自 CSV 文件保证每个虚拟用户的操作彼此独立。这样构建出来的压测其 TPS 曲线天然呈现出“脉冲”形态活动开启前持续低流量开启瞬间 TPS 陡升至峰值的 5 倍以上随后在秒杀时间窗口内维持高位最后随着用户退出而衰减。只有用这种与线上真实流量趋势一致的模型测出来的数据才具备性能瓶颈定位的参考价值。三、阶梯压测下浮现的三个隐藏瓶颈使用上述用户行为模型我们设计了五阶段阶梯加压方案每个阶段稳定运行 8 分钟起始 200 VU随后按 400→800→1600→3200 递增。这一策略模拟了流量缓慢爬坡的过程结果发现了三个在固定并发下完全没有暴露的瓶颈。第一数据库连接池耗尽。随着阶梯加压数据库连接池的使用率在 1200 VU 时开始从 30% 线性爬升到 97%接着稳定在 100% 不再回落。而固定并发测试中由于脚本总是“一口气”发起请求连接池的创建速度远快于释放速度反而掩盖了缓慢泄露的问题。实际上真实场景中业务代码在某个异常分支下未正确归还连接导致连接池水位持续上涨。我们在 JMeter 中增加了JDBC Connection Configuration监控配合自定义 JSR223 断言每 100 个请求记录一次连接池剩余量才捕捉到了这个渐变过程。第二缓存击穿配合热点数据倾斜。固定并发测试中所有请求均匀分布在商品 ID 池中缓存命中率高达 98%。但在用户行为模型中80% 的流量会集中在 20% 的热门商品上且浏览型用户会反复查看同一商品的详情。阶梯加压阶段我们观察到 Redisson 缓存的击穿次数从 2 次/分钟突然飙升至 120 次/分钟对应数据库出现大量全表扫描。排查发现是分布式锁的超时设置不合理在高并发下多个线程同时穿透缓存争抢锁导致数据库承受了本不该承受的直接压力。第三Tomcat 线程池的饱和反直觉现象。直观上我们认为线程池打满后会立刻报错但压测中 90% 响应时间平稳在 600ms 左右错误率却从 0.01% 骤然跳跃到 8%。详查后发现这 8% 的错误并不是超时而是“客户端提前关闭连接”。真实的原因是当 Tomcat 线程池饱和时连接会在 Acceptor 队列中等待超过 30 秒而 HTTP 客户端设置的连接超时为 20 秒于是大量客户端主动断开生成Broken pipe异常。这类错误在固定并发中很少出现因为固定并发不会在短时间内产生大量的等待线程。四、瓶颈定位的完整证据链发现这些问题只是第一步关键是如何在复杂的监控仪表盘中快速定位根因。我们的做法是将压测期间的监控数据划分为四个相互关联的维度并建立证据链验证机制。应用层从 JMeter 聚合报告提取 TPS、响应时间百分位、错误类型分布。重点关注 99% 响应时间与中位数的差值若差值突然扩大通常意味着存在排队效应。中间件层通过 Prometheus Grafana 监控数据库连接池、Redisson 客户端指标、消息队列堆积量。在本次压测中正是连接池使用率的持续上升曲线给出了第一指向。系统层CPU、内存、网络、磁盘 I/O但更关键的是内部组件的 runqueue 长度与线程状态切换频率。我们用top -H实时采集 Java 线程的java.lang.Thread.State分布发现 BLOCKED 状态的线程数量在瓶颈出现时刻翻了 3 倍由此锁定同步锁竞争点。业务日志在压测脚本中嵌入自定义的“压测标记”头使测试流量在 ELK 中可过滤。通过分析下单失败前后的 SQL 慢查询日志和 Redis 命令耗时最终确认了热点商品详情查询导致了大量的物理 I/O。我们要求每个疑似瓶颈的定位都必须有至少两层数据的交叉印证比如连接池耗尽这一结论必须同时满足DruidDataSource.getActiveCount()持续等于 maxActiveTomcat 线程的堆栈中出现DruidDataSource.getConnection()等待以及相应时刻的慢 SQL 数量剧增。只有这种多源数据融合的分析方法才能在 30 分钟内定位出在人工分析下可能需要数小时才能发现的隐藏问题。五、让压测回归真实的价值通过模拟真实用户行为结合阶梯式加压与多维度关联分析我们把压测从“证明系统能跑”变成了“发现系统到底哪里会先死”。这带给团队的不只是几份报告更是对系统容量模型的精准重塑。后续我们依据这些发现调整了数据库连接池的最大连接数与泄露回收策略为热点数据引入了本地缓存并结合限流算法防止缓存击穿还重新设定了 Tomcat 线程池的拒绝策略与 AcceptCount 参数最终让系统在真实大促中扛住了 3 倍于历史峰值的流量冲击平稳度过。性能测试从业者应当记住并发数只是表象用户行为才是内核。当你的脚本里有了停顿、有了随机、有了分支判断、有了真实的业务上下文压测才能成为系统健壮性的一块可靠的试金石。