1. 线程组在压测脚本里到底扮演什么角色1.1 一个线程和一个虚拟用户之间的距离性能测试学习之路写到第四篇我把Jmeter的线程组单独拎出来讲。原因很直接我带过不少刚入行的测试朋友发现大多数人对线程组的理解只停留在填线程数的地方。可实际上线程组是整个Jmeter压测脚本的调度核心你填的每一个数字最终都会变成目标服务器上真实存在的并发压力。两次压测之间TPS和响应时间差得离谱很多时候不是脚本写错了而是线程组配置的口径变了。Jmeter的线程组有几个固定选项线程数Number of Threads、Ramp-Up Period、循环次数Loop Count、调度器Scheduler以及取样器错误后的处理动作。很多人觉得这些字段看一眼就懂但真正出问题的时候往往恰恰是这些简单字段的组合逻辑没想清楚。先聊一个基础问题一个线程真的等于一个用户吗线程组里的每个线程确实会独立执行一遍脚本从这个意义上说它就是一个虚拟用户。但这个用户和真实用户之间有一个巨大的差别——真实用户在看页面、填表单、思考下一步的时候请求之间是有间隔的。Jmeter线程默认没有这个间隔一个取样器执行完立刻执行下一个中间不喘气。也就是说同样数量的线程Jmeter制造的实际请求压力往往比真实用户大得多。这也是为什么在压测脚本里要在取样器之间加定时器比如固定定时器、均匀随机定时器用来模拟操作间隙。线程组只负责多少并发操作节奏由定时器负责这两件事不能混为一谈。1.2 线程组是调度中枢不是填数字的框一个标准的Jmeter测试计划骨架长这样Test Plan 下面挂 Thread Group线程组下面挂取样器、逻辑控制器、监听器、定时器等元件。在这个结构里取样器决定发什么请求断言决定请求对不对监听器决定结果怎么记录定时器决定请求之间隔多久而线程组决定这些元件以多大的压力、什么节奏、跑多长时间。它是整个测试计划的运行容器也就是调度中枢。把这个关系搞清楚之后很多问题的定位思路就变了。比如压测结果里TPS上不去有人第一反应是换更高级的压测机或者怀疑监听器拖慢性能。但在我的经验里至少有一半的情况是线程组配置本身的问题要么Ramp-Up拉得太长压力还没汇聚测试就结束了要么线程数远小于实际需要的并发导致目标服务根本没吃饱要么循环次数和调度器设置互相冲突测试时长完全不可控。线程组配错取样器写得再规范结论也不可信。所以做性能测试第一个要较真的元件就是线程组。2. 线程数、Ramp-Up、循环次数三个参数必须连起来看2.1 线程数从业务模型反推不是拍脑袋线程数Number of Threads是最直观的参数也是被误解最多的参数。它表示Jmeter会创建多少个线程每个线程独立执行一遍脚本。在大多数场景里线程数可以近似认为是并发用户数。但注意这个并发用户数是你施加的压力它应该来源于业务而不是来源于你想不想让测试跑快点。举个例子。某个查询接口在做容量评估业务方给的峰值在线用户是5000人根据历史日志高峰时段有操作行为的用户占比大约是4%那么实际的并发请求量就是200左右。通常情况下性能测试还会在这个值的基础上放大1.5到2倍做容量余量也就是先用300到400的线程数摸底再逐步加压。反过来如果只说我要压一下系统却说不清业务并发模型是什么那线程数填多少都只是在自嗨压出来的TPS没有业务含义。还有一点经常被混淆线程数不是请求总数。想发1万次请求正确的拆法是100个线程 × 100次循环而不是1万个线程 × 1次循环。这两者的效果完全不同——线程数决定同时活跃的虚拟用户数它直接决定目标服务同时要维持多少连接和上下文循环次数决定每个用户连续跑几轮业务它影响的是总请求量。线程数越大对服务器内存、线程池、数据库连接池的并发压力越大而不仅仅是多打几个请求那么简单。2.2 Ramp-Up的数学压力爬坡的坡度靠它控制Ramp-Up Period的含义是在多少秒内把全部线程启动完毕。这里有个很简单但很关键的公式线程启动间隔 Ramp-Up时间 ÷ 线程数。比如50个线程Ramp-Up填10秒那么系统每0.2秒创建1个新线程10秒后50个线程全部开始工作。这里的单位虽然叫秒但它控制的其实是压力曲线的斜率。Ramp-Up0时所有线程在测试开始的那一瞬间同时启动相当于对目标服务形成一次冲击波。这种陡峭的压力上升方式适合模拟秒杀、抢购、活动开闸那一瞬间的访问风暴。但如果是常规的容量验证我不建议一上来就填0。真实业务流量一般是逐渐爬升的冲击式压力容易让服务在启动阶段就被打挂结果你会误判系统的真实容量。举个我自己的经历有一次压一个活动报名接口线程数填了500Ramp-Up写0结果启动瞬间大量请求连接被拒绝监控显示CPU打满。第一反应是系统扛不住500并发后来把Ramp-Up改成60秒重新跑500线程稳稳地顶住了。问题不在系统而在压力施加的方式不对。反过来说Ramp-Up设太长也有问题。前面启动的线程可能已经跑完好几轮循环了后面的线程还没全部创建完成压力无法汇聚生成的曲线像梯田一样一层一层地往上爬结果分析会变得很别扭。我常用的做法是根据每秒期待新增多少线程来反推Ramp-Up。比如希望每秒新增10个线程线程总数100那就填10秒如果线程总数1000又想压力平滑也不想测试拖太久取100秒左右比较合适。这个值没有绝对标准但它必须和线程数、测试时长放在一起算而不是随手填一个。2.3 循环次数压测的里程表最容易翻车循环次数Loop Count表示每个线程循环执行脚本的次数。如果勾选Infinite线程会一直跑直到手动停止或者到达调度器里设置的Duration持续时间。这里有个容易忽视的细节总请求次数并不总是线程数乘以循环次数。如果脚本里本身还挂了While Controller、Foreach Controller等逻辑控制器实际请求次数会按控制器逻辑放大。比如一个线程循环10次但每次循环里Foreach遍历5个订单ID那么这一个线程发出的请求就是50次。我在项目里见过最典型的翻车场景是把循环次数当作永远来用——填一个很大的数比如999999然后压到不想压了手动点停止。听起来没问题但实际操作中响应时间一旦变慢整个测试时长会无限拉长。有一次同事的脚本这么设置原本预期20分钟跑完结果因为目标服务在高峰期响应变慢压测跑了好几个小时都没结束直接延误了后续交付。循环次数这个参数适合在需要精确控制请求总量的场景使用比如回归验证某个接口连续跑2000次不出错。但如果要做稳定性测试或容量测试我更推荐用调度器控制时长这一点下面展开说。3. 取样器出错之后五个Action是压测的止损开关3.1 五个Action各自的代价线程组面板里有一项Action to be taken after a Sampler error默认是Continue。很多人在新建脚本时从来不动它但这一项在复杂场景里非常关键。它决定的是脚本里的某个取样器一旦失败当前线程、当前测试计划下一步该怎么办。五个选项的含义和适用场景我整理成了表格。错误处理动作具体行为典型使用场景Continue忽略错误继续执行当前线程的下一个取样器单接口压测只看整体成功率和TPSStart Next Thread Loop跳过本轮循环剩余取样器直接进入下一轮循环多步骤业务链路失败时放弃本轮重新开始下一单Stop Thread停止当前线程其他线程继续运行某个虚拟用户的行为已经不可能成功没必要继续Stop Test等待所有正在执行的取样器结束后停止整个测试大面积失败时优雅收场保留已完成的统计Stop Test Now立即中断所有正在执行的取样器停止整个测试线上环境出现异常需要第一时间止损这里最容易被忽略的是Stop Test和Stop Test Now的区别。Stop Test会等正在执行的请求返回或者超时后再收尾相对温和Stop Test Now则是直接把线程从执行中拽出来止损最快但代价是正在跑的请求没有完整结果统计上会出现半截数据甚至可能留下脏数据。3.2 先想清楚失败路径再决定用哪个Action我在这上面栽过一次。当时压测一个下单链路脚本是默认的Continue结果下单接口因为某个上游服务故障连续报错但脚本还在拼命地发起新订单数据库里堆了一堆异常状态的数据最后花了很长时间手工清理。从那以后我形成了一个习惯凡是涉及创建数据、修改状态的链路压测错误处理都会选得更激进要么Stop Thread要么Start Next Thread Loop让失败的虚拟用户尽早退出避免不断产生新的垃圾数据。反过来如果压的是纯查询接口个别请求失败通常是高并发下正常的连接波动完全没必要因为一两次失败就停掉整个线程组否则压力曲线会出现明显的断层测试反而不真实。这一项的选择本质上反映了你对被测系统失败路径的理解失败之后是应该继续往下走还是跳过本轮还是整个测试叫停。它不是随便勾一个就完事的配置项。4. 调度器与压测时长把跑多少遍改成跑多久4.1 固定循环模式和固定时长分别什么时候用线程组的调度器Scheduler解决了跑多少遍和跑多久之间的问题。启用调度器后可以设置Duration持续时间单位秒配合循环次数勾选Infinite压测就能精确运行指定秒数。在很多长时间稳定性测试里这个组合几乎是标配。固定循环模式更适合功能验证类压测比如想确认某个接口在100并发下跑2000次请求有没有报错用线程数 × 循环次数非常直观跑完即止数据也可预期。但它的缺点也很明显——响应时间波动会直接影响总时长。响应快测试提前结束响应慢测试被无限拉长。这一点在对比测试里特别致命。比如你在调优前跑了一次固定循环压测调优后再跑一次两次的请求总量虽然一样但时长可能差了20%TPS、平均响应时间这些指标就失去了可比性。固定时长模式则不同大家都在同一个时间窗口里采样数据口径一致对比才有意义。4.2 Duration、启动延迟和顺序执行怎么配合调度器里除了Duration还有一个容易被忽视的字段Startup delay启动延迟。它表示线程组创建后先等多少秒再开始创建线程。这个字段在多线程组场景里非常有用。默认情况下同一个测试计划下的多个线程组是并行启动的除非你在测试计划节点上勾选Run Thread Groups Consecutively顺序执行线程组。顺序执行会让前一个线程组完全结束后一个才开始适合严格分阶段的压测。但有些场景我既不想让它们完全串行又不想让它们完全并行——比如有一个基础数据初始化的线程组希望它先跑一会儿再启动核心交易线程组这时候用Startup delay做错峰启动比硬拆成多个测试计划方便得多。我实际使用中会这样配基础数据线程组正常启动交易线程组Delay设30秒给基础数据预热留出时间两边的压力曲线还能部分叠加更接近真实混合业务流量。4.3 一个固定时长压测的完整配置示例举一个我常用的配置实例。要对一个订单查询接口做5分钟容量验证目标并发200我一般这样填线程数Number of Threads200Ramp-Up Period60Loop Count勾选Infinite调度器勾选SchedulerDuration填300这里有个细节要提醒Duration是从线程组启动开始算的总时长里面已经包含了Ramp-Up的时间。按上面的配置前60秒是200个线程逐渐创建的过程后240秒是全部线程在线的稳定加压阶段到300秒时Jmeter停止发起新的循环正在执行的请求继续跑完然后脚本结束。整体Active Threads曲线应该是先爬坡、再平台、最后回落。如果你填了Duration却忘了勾Infinite循环次数又不是很大有可能出现循环已经跑完但Duration还剩很多的情况测试会空等剩余时间这点配置时要留意。5. SetUp和TearDown线程组压测前准备和压测后清理的正确姿势5.1 为什么不用主线程组做准备工作Jmeter提供了两种特殊线程组SetUp Thread Group前置线程组和TearDown Thread Group后置线程组。SetUp会在其他普通线程组开始之前执行TearDown会在所有普通线程组结束后执行。它们的定位就是压测前置准备和压测后清理。很多人会问我不就是把登录请求放在主线程组最前面吗效果一样吧还真不一样。如果登录请求在主线程组里它会被计入压测统计污染TPS、响应时间、错误率这些关键指标。举个例子你想压测下单接口但每个线程先登录再下单。登录接口如果平均响应时间比下单还慢最后统计出来的下单接口TPS实际上是登录加下单的混合值根本不能说明下单接口的性能。正确做法是把登录放到SetUp线程组里只执行必要的次数拿到token后传给主线程组使用。这样主线程组统计到的完全是业务接口本身的性能数据。5.2 拿token、造数据、清数据一套可复用的模板我处理需要鉴权的接口压测时最常用的一套模板是这样的SetUp线程组线程数设1循环1次。里面放一个登录取样器用JSON Extractor或正则表达式提取器把token取出来再用JSR223后置处理器把token写入Jmeter属性脚本大致长这样props.put(authToken, vars.get(token));主线程组里通过${__P(authToken)}读取这个属性放到HTTP Header Manager的Authorization字段里这样每个线程发出的请求都会带上这个token。TearDown线程组在压测结束后执行清理动作比如调用清理接口删除压测产生的测试数据避免影响后续测试或污染测试环境。这里面有几个关键点。第一线程组之间的变量默认不共享但属性Property是全局的所以跨线程组传值要用__setProperty配合__P或者用JSR223里的props。第二SetUp线程组的线程数通常设1就够了因为登录只是准备工作不是压测目标只要能拿到有效token就行。第三如果压测需要模拟多用户建议在CSV文件里预先准备多组账号而不是在SetUp线程组里并发登录——并发登录不仅会把认证服务搞得很慢还可能触发单点登录互踢反而制造麻烦。TearDown线程组虽然不是每个项目都必需但养成习惯之后能避免压测垃圾数据越积越多尤其是对数据库有写入操作的场景。6. 线程组执行曲线与三个真实翻车复盘6.1 Active Threads Over Time到底怎么读压测执行的时候除了看TPS和响应时间我还会挂一个Active Threads Over Time监听器实时观察线程组实际创建和退出的情况。这个监听器的曲线直接反映了Ramp-Up和调度器是否按预期工作理想形态是平滑爬坡、平台期稳定、结束时平缓回落。如果曲线出现锯齿状抖动通常说明有线程提前退出——比如触发了Stop Thread或者Ramp-Up设置得过陡导致目标服务开始丢弃请求。读这条曲线最大的价值在于它能第一时间暴露出你配置的压测模型和实际施加的压力模型之间的偏差。有时候你以为自己在压100并发看曲线才发现线程爬坡太慢真正达到100并发的时间段只占了测试的一小部分结论自然不可靠。6.2 翻车一Ramp-Up0服务被启动风暴打挂之前提到过的活动报名接口我再展开说说完整过程。当时为了赶进度我图省事把500个线程的Ramp-Up填成了0想着快点开始。结果测试一开始监控面板上CPU直接飙满应用日志里全是Connection refused。第一轮测试就这样以大量连接错误收场我差点就在报告里写系统无法支撑500并发。后来我把Ramp-Up改成60秒重新压同样500线程服务平稳运行TPS也回到了合理区间。复盘之后确认失败不是容量问题而是启动风暴——瞬间500个请求同时到达服务的连接池、线程池连预热都没完成直接被打懵了。这次之后Ramp-Up0只在明确要模拟瞬时冲击的场景才用常规容量验证一律按平滑爬坡来配。6.3 翻车二循环次数当永远用压测时长失控另一个案例是接手同事的脚本循环次数填了999999问他原因答曰反正压到不想压了就手动停。有一次团队用它做回归原本预期20分钟跑完结果因为目标服务在压测中段响应时间涨了不少总时长被拉到了3个多小时直接延误了版本发布。根因就是固定循环模式下测试结束条件是循环次数×线程数全部完成响应时间一旦波动总时长就完全不可控。修正方案很简单循环次数勾成Infinite在调度器里填Duration比如600秒把观察窗口固定下来。下次你配置线程组的时候可以先问自己一句这次测试是按请求量结束还是按时间窗口结束想清楚这一点就能避免这类失控。6.4 翻车三SetUp线程组被当成先跑完的保险登录态错乱最后一个案例来自同事的项目。他在SetUp线程组里用了5个线程去登录本意是多拿几个token备用结果主线程组里一部分请求用错了token鉴权失败率莫名飙升。排查了很久才发现问题不只是token引用写错更隐蔽的是SetUp线程组虽然会在其他线程组之前执行但它在短时间内并发登录多次目标系统的会话策略把先前的登录态踢掉了导致后面拿到的token全部失效。这种问题在登录接口没有明显报错时很难发现曲线表面上只是鉴权失败率偏高。修正后的做法很朴素SetUp线程组只保留1个线程、1次循环登录一次拿一个有效token如果确实需要模拟多用户并发就在CSV里准备多组账号放到主线程组的参数化里绝不在SetUp线程组里临时并发登录。复盘这几个坑我最大的体会是线程组配置出问题多数时候不是不会填数字而是没想清楚我要给目标服务制造什么样的压力曲线。如果你刚开始接触性能测试配置线程组之前先回答三个问题这个场景的并发模型是什么压力是陡升还是缓升测试是按请求量结束还是按时长结束这三个问题想清楚了线程组那几个参数基本不会填错。这也是我做性能测试这几年觉得最值得分享的一条经验。
