性能测试做到一定阶段你会发现一个比较残酷的现实单接口压测做得再漂亮问卷报告里写“并发500平均响应时间150ms”放到真实业务流里一跑立刻露馅。原因也很简单——线上流量从来都不是“一个接口单独跑”而是几十个接口按不同比例同时进来接口与接口之间还有数据依赖、资源竞争和排队关系。你只压单个接口等于用一个乐高零件去验证整台机器的强度参考价值非常有限。混合场景测试和稳定性测试恰恰是补上这块短板的两门必修课。混合场景解决的是“压测流量像不像真实流量”的问题稳定性测试解决的是“系统在这种流量下连续跑十几个小时会不会慢慢垮掉”的问题。这两个方向我在项目里反复折腾过也踩过不少坑这篇就把设计思路、执行流程、判定标准和排查技巧完整拆开讲一遍适合那种已经在单接口压测上入门、想把性能测试往下做深的同学参考。1. 混合场景测试把压测从“单接口玩具”变成“生产流量仿真”1.1 场景设计的第一性问题你压的到底是什么流量很多人第一次做混合场景第一反应是“把所有接口都放进去每个接口分配几个线程一起跑”。这个思路方向没错但如果只是把接口平均分线程出来的结果基本没法用。因为真实用户的访问量分布从来不是平均的购物网站上“浏览商品列表”的请求数量可能是“提交订单”的几十倍上百倍你把两个接口按相同线程数压订单接口被过早打满浏览接口又没到真实压力整个场景失真。所以混合场景设计的第一问不是“放哪些接口”而是“你压的流量是哪个时间窗口的真实流量”。做这步之前我一般会先找三类数据线上网关或负载均衡的接口调用量统计按天或者按小时维度核心业务报表里各业务的UV/PV数据至少取最近7天避免单日异常运维侧已有的业务高峰时段水位数据用来决定压测目标量级。比如做某模拟电商项目X的性能摸底我从线上监控里拉到的接口占比大概是商品列表浏览35%、商品详情25%、购物车操作15%、提交订单15%、支付结果查询10%。这个比例就是整个混合场景的“业务模型骨架”。后续所有线程分配、请求比例配置都围绕这个骨架展开而不是自己拍脑袋定。提示如果项目没有埋点或监控数据一个次优方案是找产品/运营要一份典型用户路径分析报告按点击流或转化漏斗折算接口比例。宁可要一个大概正确的比例也不要平均分配。1.2 业务占比建模从线上监控报表到脚本配置拿到了接口比例接下来是把它转化成压测工具里的实际配置。这里牵扯一个关键概念混合场景里“占比”控制的是请求数比例不是线程数比例。一个接口如果响应时间慢单位时间内能跑完的请求数就少要达到同样的请求占比就需要给它分配更多并发线程。反过来响应时间快的接口少量线程就能打出很大的请求量。我在JMeter里一般用两种方式实现占比控制其实哪个顺手用哪个一种是用Throughput Controller它的原理是控制该控制器下采样器的总执行次数占比。比如“商品列表浏览”占总请求量的35%那么在这个控制器下放浏览接口的采样器Percent Execution填35JMeter会按整体迭代节奏去匹配这个比例。这个方案的优点是直观缺点是JMeter版本和线程组的计算逻辑偶尔会有偏差比例值需要调尤其在TPS很高的时候误差会被放大。另一种是直接用加权开关配合Switch Controller加自定义变量。用一个线程组跑一个随机分配器按预设权重把不同比例映射到不同的请求分支。这个方案更可控我后来越来越倾向于这个做法因为权重值可以直接写在JMeter属性或者CSV文件里后续调整比例不需要改动脚本结构。Step 1. 在JMeter的Test Plan下创建两个Thread Group一个跑浏览类接口列表详情一个跑交易类接口加购下单支付查询。Step 2. 浏览类线程组按线上峰值总TPS的60%配置线程数交易类按40%配置具体数值用线上TPS换算。Step 3. 在每个线程组内部用Switch Controller加权重变量做接口分流权重值从CSV读取。Step 4. 给所有写操作接口加购、下单、支付加上Constant Timer模拟用户操作间隔。Step 5. 最后跑30分钟预压统计各接口的实际请求数和设定的占比对一遍偏差超过5%就调整权重。这里还要提醒一句有些压测平台自带“场景编排”能力比如按脚本权重自动分配并发或者按模型生成流量。这类平台可以省不少事但底层原理还是上面这套理解模型比会点按钮有用得多。1.3 混合场景里最容易忽略的三个细节第一个细节是思考时间。真实用户不会像机器一样0间隔地连续点按钮看商品列表至少停留几秒阅读详情再花几秒最后决定下单。压测脚本里如果不加思考时间打出来的请求密度远超实际用户行为系统会被人为压垮。但思考时间也不能照搬网上模板得结合业务特点工具类产品操作间隔短内容类产品阅读时间长。我一般先按线上访问日志里“用户相邻请求间隔”的实际分布取中位数再在JMeter的Constant Timer里给各接口加上。第二个细节是数据量级与数据分布。混合场景里各接口之间经常存在数据依赖例如支付查询得先有订单号加购得先有商品ID。我遇到过很典型的坑脚本里所有用户从同一个商品ID池里取数压测中后段热点商品全部命中缓存响应时间曲线看起来很漂亮但实际是数据热点造成的虚假表现不是系统真实水平。所以商品ID、用户ID、订单号池子要足够大并且要按真实业务的热度分布来随机读取而不是全用热门数据。第三个细节是接口间的上下游依赖。真实系统里一个下单请求背后会调库存服务、调用优惠服务再发MQ消息给履约系统。做混合场景时如果只压网关入口接口而忽略了下游依赖服务你对“系统”的压测其实只覆盖了前半段链路。这种情况下需要在脚本里保留完整的接口调用链或者至少在下游服务压上足够的负载模拟真实的资源争抢。我就见过一个项目入口接口压得飞快但下游数据库连接池因为没压力表现正常一上生产活动瞬间被真实流量打穿连接池。2. 稳定性测试长时间运行才是性能问题的照妖镜2.1 为什么峰值压测通过不代表系统能稳定运行这里先讲一个我自己的教训。有次做某跨平台系统的性能验收峰值压测结果很好看TP99响应时间稳定在180毫秒错误率0.02%所有指标都在线。结果放到生产环境跑了不到三个小时报文处理速度肉眼可见地下降又过一小时开始频繁超时。后来一查是某中间件客户端在长时间运行下慢慢累积连接数连接池用的连接不归还系统资源一点点被蚕食。这种问题峰值压测里基本不可能暴露因为峰值压测通常只持续15到30分钟内存泄漏或句柄泄漏还没到临界点。稳定性测试有人也叫Soak Testing、长时间浸泡测试解决的就是这个问题在接近真实负载但略低于峰值的压力下连续运行较长时间观察系统在资源累积、缓存失效、调度抖动、GC频繁等慢变量作用下性能是稳定、缓慢劣化还是会突然崩溃。它和压力测试的区别在于压力测试追求的是“打爆系统的拐点在哪”稳定性测试追求的是“系统在持续负载下能不能扛住”。2.2 稳定性测试的时长、负载与通过标准稳定性测试的时长业界没有一个绝对标准但工程实践里一般按下面这个逻辑取如果系统的活动周期按小时级别看至少压12小时让他们覆盖完业务的完整波峰波谷如果按天级别看至少压24小时覆盖一个完整自然日。我实际做过的大多数稳定性测试都在8到24小时之间。8小时是一个底线低于这个时间很多泄漏类问题还来不及充分暴露超过24小时工程成本和管理成本都会陡增除非是金融交易类系统或核心计费系统一般不太值当。负载强度方面我推荐压在“预估峰值负载的80%”这个位置。为什么是80%而不是100%因为如果压满峰值系统可能因为正常波动偶发报错测试结果里很难区分“负载过高导致的必然错误”和“长时间运行导致的缺陷”而80%的负载给系统留出了一定的buffer这时候如果还出现错误率上升或响应时间劣化基本可以确定是系统自身存在问题而不是负载压出来的噪音。有些人会压会员60%负载那个更保守通常用于预测试正式稳定性测试用80%更合适。通过标准不能只拍一个“错误率小于1%”我会把稳定性测试的通过条件拆成四层来评估判定维度通过标准对应监控手段成功率业务成功率保持平稳无持续下降趋势压测工具事务成功/失败统计响应时间TP99/TP500曲线平稳劣化幅度不超过基线20%压测工具聚合报告、APM响应时间TPS稳定性吞吐量围绕目标值小幅波动波动幅度不超过±10%压测工具实时TPS曲线资源健康度CPU/内存/连接数无单调增长GC和线程池状态正常系统监控平台、JDK工具注意这里特别强调“无持续上升趋势”。比如内存使用率时不时冲到70%然后又降下来这是正常GC徘徊但如果内存曲线从测试开始到结束底部位置一直在抬高哪怕当前还没OOM也要高度怀疑是泄漏。稳定性测试最大的价值就是看这种趋势而不只是看某一刻的数值。2.3 稳定性测试期间要盯的五个监控面长时间压测时最容易犯的错误是脚本一启动人就走了等到第二天早上回来看报告。这不行中间过程你得定时看一眼数据。我差不多每隔30到60分钟截一次监控面板的图记录每个时间点的关键数值。五个必须盯的监控面如下第一应用服务层。重点看线程池活跃线程数、队列积压量、连接池使用率。线程池活跃数如果随时间推移单调上涨说明有任务处理不完在积压可能是线程卡死或资源争抢加剧。第二JVM层。堆内存使用率、GC频次、GC耗时这三项是重头。Full GC如果从每小时一次变成每10分钟一次直接说明动态创建对象的速率超出了回收速率如果GC暂停时间持续走高响应时间的尾巴一定会逐渐变长。用jstat -gcutil每5分钟记录一次就能看到趋势。第三操作系统层。CPU的空闲率、内存可用量、磁盘I/O await时间、网络带宽占用。这里我想提醒的是别忽略磁盘稳定性测试跑得久日志文件会持续增长磁盘写满或者日志轮转频繁都会影响性能。第四中间件层。数据库连接数、缓存命中率、消息队列积压量这三项最关键。数据库连接数如果只升不降大概率是连接池泄漏或者慢SQL把连接拖住了消息队列积压量持续增长说明下游消费速度跟不上上游生产速度迟早会出问题。第五业务数据层。比如当前有效的订单总量、库存余量、分布式缓存里键值总量。有些系统跑久了之后缓存数据会不断膨胀或者表里的数据量增长导致查询变慢这些都是稳定性测试才能暴露的“数据型劣化”。3. 压测执行阶段从脚本调通到拐点定位的完整流程3.1 执行前的环境巡检连接数、句柄、端口在进入正式测试之前务必花半小时左右做环境巡检。我见过太多人脚本还没跑起来先因为系统资源限制被泼了一盆冷水。以下这几项每一条都是踩过的真实教训文件句柄限制压测期间应用服务器和压测机都需要大量打开socket和文件。Linux下默认的ulimit -n可能只有1024不修改的话线程一多直接报“Too many open files”。我一般在压测前把应用服务器的nofile调大到65535压测机也同步调整。端口范围限制压测机向服务器发起大量并发连接时本地临时端口可能不够用。用高并发压测时可以把net.ipv4.ip_local_port_range调整为1024 65535同时开启net.ipv4.tcp_tw_reuse来加快TIME_WAIT状态连接的复用。这个不调经常压着压着就出现“Cannot assign requested address”。数据库连接数上限稳定测试一跑就是十几个小时如果数据库连接池最大连接数配置过小早高峰流量一来连接就排队。开始前先查一下数据库端max_connections和应用侧连接池配置是否匹配。日志级别压测前把应用日志级别从DEBUG切回INFO如果可能压测时把业务日志直接打到异步Appender。否则光是日志同步写盘就能拖慢20%以上的吞吐量测出来的数据会严重失真。巡检完之后我会用脚本先做一轮“冒烟压测”并发度100跑3分钟确认脚本能持续且稳定地产生请求采样器没有大量报错。这轮跑完再进入正式测试阶段。3.2 阶梯加压与性能拐点识别正式执行时我不推荐一次性把并发打到目标值而是用阶梯加压的方式逼近目标。这样做有几个好处首先能帮助确认系统在负载上升过程中是否存在某个临界点也就是性能拐点其次如果系统在较低并发时就出现错误也能第一时间发现避免带着严重问题继续跑。用JMeter实现阶梯加压很简单把线程组里的Ramp-up period拉长让并发在几分钟内逐步爬升或者用插件里的Stepping Thread Group配置阶段化加压。阶梯加压过程的观察重点是找到响应时间和吞吐量的拐点。在并发量从低到高爬升的过程中吞吐量会随着并发增加而增加响应时间缓慢上升但在某个并发临界点吞吐量增长会趋于平缓而响应时间开始急剧上升这个点基本就是系统的性能拐点。如果拐点远低于业务预期目标你需要马上停下检查而不是继续盲目加压因为继续加压只会把系统压垮得不到更多有用信息。我习惯在脚本里加一个简单的自定义断言响应时间超过2秒就标记为失败事务。这样压测报告里的错误率就不只是“连接失败”和“HTTP错误码”还包括“业务层面的超时”。这个细节会让最终报告提供的信息量大很多。3.3 结果数据解读别只盯着平均响应时间压测跑完之后最忌讳直接看JMeter聚合报告里的“Average”列就下结论。平均响应时间的欺骗性很大一个TP99本来就400毫秒的系统只要中间出现1%的5000毫秒请求平均值可能直接跳到700多看起来“整体很差”反过来如果尾部大量慢请求被平均掩盖平均值又可能“好看得过分”。我在结果分析时固定按下面这套顺序来Step 1. 看错误率趋势。先把时间维度拉出来确认错误率没有集中爆发的片段。Step 2. 看TP90/TP99/TP500分布曲线。如果TP90很平稳但TP500剧烈抖动说明存在少部分被阻塞或重试的慢请求这时要去查阻塞来源而不是只看平均。Step 3. 把TPS曲线和资源使用率曲线对齐。如果TPS下降的同一时刻CPU使用率或GC暂停也出现尖峰那基本能锁定瓶颈方向。Step 4. 用Apdex指标做个宏观体检。Apdex把请求按T设定的满意度阈值比如2秒划分为满意、可容忍、失望三档算出来的分数在0到1之间。报告里给Apdex比给平均响应时间更能说明用户体验水平。关于响应时间的分类口径也建议统一弄清楚网络传输时间、服务端处理时间、排队等待时间和客户端解析时间压测工具里显示的时间通常是“完整请求往返时间”和APM里面看到的“服务端处理时间”天然存在差异。如果两边都对不上先检查监控口径不要急着下“系统变快/变慢”的结论。4. 常见问题与排查技巧实录4.1 连接池泄漏症状、定位与验证稳定性测试中遇到概率最高的一个问题就是连接池泄漏。表现形态很典型压测刚开始的一两个小时内一切正常越到后面应用日志里出现越来越多“获取连接超时”或“连接池耗尽”的报错数据库侧又发现活跃连接数一直往上走。原因是某段代码从连接池里取出了连接但异常分支里忘记归还时间一长可用连接被耗尽。定位这种问题如果应用里接入了APM直接看连接池监控里活跃连接数与使用率曲线没有APM就用jstack连续抓几份线程栈查找线程卡在JDBC拿连接或阻塞在getConnection上的堆栈。找到嫌疑线程后再看对应的业务代码。我个人排查时有几个常见的检查点try-with-resources是否包含了所有分支、多线程代码里连接引用是否被局部变量泄露到外层、内部嵌套事务里的连接是否在子事务关闭时被提前归还但状态异常。验证修复是否有效的方法也不复杂修复前先跑2小时把内存和连接池曲线记录下来修复后同样负载再跑2小时对比两张图中的连接池使用趋势。如果修复后曲线是平稳的水平线而不是持续爬坡问题就算彻底解决。4.2 内存缓慢增长与GC异常内存问题表现和连接池泄漏有点像都是“跑着跑着慢慢变差”但从监控指标上可以区分连接池泄漏大多伴随数据库连接数上升内存泄漏则表现为堆内存使用率的“下限”不断抬高同时Full GC越来越频繁。排查内存问题时我第一步永远是用jmap -dump:live,formatb,fileheap.bin pid抓堆转储再用分析工具如MAT或者JProfiler看支配树和泄漏报告。重点排查对象是静态集合类、缓存类组件、EventListener没有反注册以及ThreadLocal没有清理这四类。特别提醒一句抓堆转储之前先jmap -histo看一眼很多问题其实只靠对象数量直方图就能定位不需要每次都抓完整的堆转储文件那个文件动辄几个G对生产影响也大。GC异常里有一个容易被忽视的坑显式调用System.gc()。有些框架或者业务代码里为了“主动清理”会调用它在压测期间大量触发Full GC把响应时间曲线拉出锯齿状。排查时用jstat -gcutil看到Young和Full GC交替出现但内存总量并不高就要到代码里搜一下System.gc()或者RMI相关的定时触发逻辑。4.3 线程池耗尽与线程Blocked线程池耗尽比连接池泄漏更隐蔽因为它的直接表现很像是普通的高负载大量请求超时、CPU整体跑满。但仔细观察会发现一个特征线程池活跃线程数持续处于最大值而且线程状态为WAITING或BLOCKED的比例极高。如果用的是Java标准线程池直接看ThreadPoolExecutor的ActiveCount和QueueSize。如果线程数打满且队列持续积压要么是任务本身执行太慢要么是任务里嵌入了同步阻塞调用比如同步RPC、数据库慢查询、分布式锁等待。用jstack抓线程栈后重点找那些卡在LockSupport.park、AbstractQueuedSynchronizer.acquire和JDBC网络读写的线程。有一次排查某跨平台系统的超时问题压测期间线程全部阻塞在Redis分布式锁的等待上问题是锁的持有时间在并发上去之后被放大线程越积越多最后把整个业务线程池拖死。遇到线程池耗尽不要上来就“把线程数调大”。线程数越大上下文切换开销越高而且对下游资源的争抢越严重经常会让系统雪上加霜。正确做法是先找出线程到底阻塞在哪个资源上把那个资源的瓶颈解决掉线程池自然就缓过来了。4.4 问题速查表把我在性能测试实践中碰到的高频问题整理成一张速查表压测时遇到对应现象可以直接按表索骥现象直接表现高阶指标初步排查方向连接池耗尽获取连接超时DB活跃连接数持续上升代码分支未归还联接、池最大值配置偏小内存泄漏堆内存下限持续抬高Full GC越来越频繁静态集合、缓存无淘汰策略、ThreadLocal未清理线程池耗尽大量任务超时活跃线程打满、队列积压线程阻塞在锁/RPC/慢查询上GC暂停响应时间尾部抖动GC耗时尖峰大对象分配、堆过小、显式System.gc()热点数据缓存击穿TPS峰值时段错误率上升缓存命中率暴跌缓存过期时长设置、热点Key集中失效数据库慢SQL累积TPS缓慢下降DB连接等待时间上升慢SQL未优化、数据量增长导致索引失效磁盘写满服务整体响应变慢磁盘I/O await高、日志卡顿日志滚动策略未配置、压测日志量过大最后再分享一条个人体会做混合场景和稳定性测试真正难的不是把工具配好、把脚本跑通而是面对一堆并存的现象时能冷静区分哪些是负载导致的正常表现哪些是系统缺陷的早期信号。我的习惯是压测过程中每隔一段时间就在一个记事本里记下当前的现象和可能原因哪怕后来证明猜错了这些记录也比跑完只看一张聚合报告管用得多。性能测试是个慢功夫把场景设计得贴近真实把时间跑得足够长很多藏得深的问题自然就露出来了。