★ FEATURED ARTICLE 跑过几次JMeter并发测试之后你会发现真正决定结果靠不靠谱的往往不是脚本写得有多花哨而是线程组里那几个参数怎么搭配。线程数、Ramp-Up、循环次数、Duration每一项单独看都很好理解但组合在一起就成了最容易踩坑的地方。这篇东西就围绕JMeter并发测试核心参数配置把参数背后的原理、常见搭配和我在实际压测中踩过的坑一次性说清楚适合刚接触压测的测试同学也适合那些跑过几轮但总觉得结果不太对劲的同行。1. 并发测试前先把这三个概念理清楚1.1 线程、虚拟用户与“并发”的真正含义JMeter里的线程Thread就是虚拟用户线程数就是同时模拟多少用户操作。但这里“并发”不是指某一秒内所有人同时按鼠标而是一种“活跃用户持续操作”的状态。假设你设置100个线程、循环次数为无限这100个线程会按照一定的节奏去发请求有的人刚发完在等响应有的人已经拿到响应准备发下一个整个过程是动态的。我在培训新人时经常打一个比方一个餐厅有100个座位但不代表100个客人会同一秒把菜点完。有人刚坐下有人已经吃完走了这种“满座”状态才是真实的并发场景。JMeter线程组要模拟的就是这种“座位一直有人坐”的稳态而不是瞬间的并发爆发。这个概念没理清后面所有参数都可能配歪。比如很多人觉得“并发数线程数”就够了但实际响应时间会直接影响单位时间能完成的请求量线程数设定了活跃用户数而吞吐量由响应时间决定。这也是为什么后面所有估算都要把响应时间这个变量带进去。1.2 循环次数与持续时间两种压测模式怎么选线程组面板里有“循环次数”和“调度器”两个区域。循环次数指每个线程执行脚本的遍数调度器则用来控制测试的启动时间和持续时间。新手最常见的困惑是到底填循环次数好还是用调度器好我的习惯是分场景如果只是做功能验证或冒烟测试比如我要确认一个接口在20个并发下跑10次没有问题就填循环次数10跑完就停如果做持续压测比如“200并发跑5分钟看稳定性”那就把循环次数勾成“永远”再用调度器设置持续时间300秒。为什么持续压测推荐用“永远持续时间”因为固定循环次数会在测试快要结束时出现明显的“线程退出”阶段所有线程逐步跑完最后一遍后退出整个过程的吞吐量曲线尾部是掉下来的统计平均值时会把这部分拉低。而“永远持续时间”模式下线程会在整个Duration内持续循环到点统一停止前后更均匀统计数据更接近业务高峰期时的稳定状态。1.3 调度器里的启动延迟与持续时间不是一回事调度器面板里有两个输入框启动延迟Startup Delay和持续时间Duration。这两个值的区分非常关键很多人混在一起填。启动延迟是指测试开始后先等待多久才真正启动线程。比如你设置了启动延迟60秒意思是点击运行之后JMeter会先傻等60秒然后才开始创建线程。持续时间则是线程启动之后持续运行多久。注意它不包含启动延迟的时间是从线程真正开始跑算起的。所以如果你想要“从测试启动到结束一共5分钟”正确做法是启动延迟填0或者不填持续时间填300秒。如果你填了启动延迟60秒、持续时间300秒那么从点击运行到结束总共是360秒。这个时间差平时可能无所谓但在对接自动化执行平台、需要精确控制测试窗口的时候差一分钟都可能导致整条流水线的时间预算超支。2. JMeter核心参数逐个拆解与配置要点2.1 线程数多少才合适从目标TPS反推而不是拍脑袋线程数设置的一个常见误解是“并发越高越好”。实际上线程数过高会引发大量线程争抢CPU和网络资源甚至让JMeter本身成为瓶颈测出来的数据全废。更合理的做法是从目标TPS反推需要的并发用户数。核心公式是并发用户数 ≈ 目标TPS × 单请求平均响应时间单位秒举个例子订单查询接口线上业务要求支撑峰值TPS为500从历史监控看这个接口的平均响应时间约200毫秒0.2秒。那么理论上需要的并发用户数就是500 × 0.2 100个线程。这个数字的含义是在响应时间不变的理想情况下100个用户持续操作就能产生500TPS。但这个公式算出来的是理论下限实际压测场景我通常会在估算值基础上再加30%到50%的余量因为真实环境中响应时间会抖动、服务端连接池可能排队、网络偶发波动。比如上面算出100第一轮压测我会先压150个线程看看曲线然后逐步往上加直到找到系统拐点。2.2 Ramp-Up Period千万不敢设0线程组面板里有一项叫“Ramp-Up Period秒”含义是在多少秒内把线程全部启动完。这个参数我见过太多人直接填0结果就是瞬间把所有线程砸上去服务端瞬间被打蒙轻则超时率飙升重则直接把测试环境搞挂。举个例子1000个线程Ramp-Up设0JMeter会在几毫秒内创建1000个线程并同时向服务端发起请求。服务端的线程池、数据库连接池在那一瞬间被打满大量请求排队平均响应时间从正常的200毫秒变成2秒错误率从0变成30%。但这个结果并不是真实业务峰值下的表现因为真实用户不会在同一毫秒集体涌入。那Ramp-Up到底填多少我通常按“每秒启动速率”来反推。如果我要做200并发、希望每秒启动10个用户那Ramp-Up就是200 / 10 20秒。如果是快速估算一般建议Ramp-Up取值在“线程数/5”到“线程数/10”之间。比如100个线程Ramp-Up可以是10到20秒。这个区间的初衷是让并发呈现平滑上升的过程既不会瞬间爆量也不会因为启动太慢导致整个测试时间被拉长。2.3 循环次数与Duration的配置组合把循环次数设为“永远”并配合持续时间是持续压测场景下最稳定的组合。配置路径如下在线程组面板勾选“永远”复选框新版界面写的是“Infinite”然后在调度器里勾选“持续时间”填入想要的秒数。比如“100并发跑10分钟”的配法就是线程数100Ramp-Up设为20秒循环次数勾“永远”调度器里勾选“持续时间”填600。这样线程会在20秒内逐渐启动到100个然后持续跑满600秒到点后统一停止。这里有一个很多人忽略的细节勾选“永远”之后如果不填持续时间测试就会一直跑下去直到手动停止。手动停止时JMeter会尝试等待当前正在执行的采样结束如果采样请求的响应超时时间很长停止过程会拖很久。所以任何“永远”模式都必须搭配一个明确的持续时间否则线上压测场景容易失控。2.4 普通线程组 vs bzm并发线程组怎么选除了内置的标准线程组Thread GroupJMeter里还有两款常用的第三方线程组bzm - Concurrency Thread Group 和 Ultimate Thread Group都来自Plugins Manager。它们在阶梯加压场景下比普通线程组好用得多。普通线程组的加压方式是“数量固定Ramp-Up固定”线程启动完就保持恒定适合做稳态压测。但如果你想知道系统在50、100、200、300并发下各自的表现用普通线程组就得人为分成多轮测试或者用多个线程组叠在一起非常麻烦。bzm连续线程组提供了四个核心参数Target Concurrency目标并发数、Ramp Up Time达到目标用时、Hold Load Time保持时间、Steps阶梯数。比如我设置目标并发300、Ramp Up Time 120秒、Steps 6它就会在120秒内分成6个阶梯每20秒增加50个并发每一级保持一段时间非常适合观察系统性能随并发上升的变化趋势。Ultimate Thread Group则用表格方式配置可以自定义多个线程启动段每一段都可以设置起始线程数、结束线程数、启动耗时和保持时间灵活性最全但配置也稍微复杂。大多数场景我用bzm就够了Ultimate主要用在需要多阶段复杂压测模型时。3. 别忘了HTTP请求层和JVM参数的配合3.1 连接超时与响应超时的设置逻辑很多人在JMeter里只关注线程组参数HTTP请求里的超时时间随便填或者干脆不填结果压测过程中线程大量挂在“等待响应”的状态并发数看着是100实际上有效请求可能只剩一半。这个细节对测试结果影响非常大。”连接超时“指的是TCP连接建立的等待时间超过这个时间就报Connection Timeout。压测时网络偶发抖动或服务端句柄耗尽都会导致连接建立变慢如果连接超时设得过大所有线程都在排队等连接整个压测的实时并发能力就被拖垮了。我的经验是连接超时一般设1000到5000毫秒具体看被测服务所在网络的正常握手耗时。“响应超时”是请求发出后等待服务器返回的时间上限。这个值的设定逻辑要跟着业务走线上用户最多能容忍多久如果你的接口SLA规定P95响应时间不超过800毫秒那压测时的响应超时设5秒已经非常宽容了。响应超时设太大会导致一个明显问题服务端如果发生慢请求堆积JMeter线程全挂在等待响应上后续请求发不出去但线程数还是满的表面看并发达标了真实吞吐量却很低。这部分数据会在结果里暴露出来吞吐量上不去、平均响应时间被拉高。3.2 Keep-Alive与连接复用对并发量统计的影响HTTP请求配置里有一个“Keep-Alive”复选框默认是勾上的。有些新手会好奇勾和不勾有什么实质区别。勾上Keep-Alive后每个JMeter线程会复用同一个TCP连接向服务端发送多个请求这与浏览器等真实客户端的默认行为一致也更接近线上场景。不勾的话每个请求都会新建一个TCP连接压缩测试结束后连接处于TIME_WAIT状态积压多了会占满压测机本地可用端口表现为“Address already in use”一类的报错吞吐量也会被连接建立的额外开销拉低。在并发量大的时候我会通过linux命令行观察本机连接状态判断是否存在端口耗尽问题netstat -an | grep TIME_WAIT | wc -l netstat -an | grep 8080 | wc -l如果TIME_WAIT数量持续高企JMeter自身的连接管理参数也需要调整。实际压测中如果压力机不够Keep-Alive通常是要勾上的它会避免无谓的连接开销让压力集中打在被测服务上。但要注意如果被测服务本身限制了最大连接数Keep-Alive长连接占用连接池的时间会更长可能反而提前触发服务的连接数上限这时你需要结合业务实际情况决定。3.3 JVM堆参数与命令行压测的正确打开方式JMeter本身是Java应用并发线程多了之后JVM堆内存不够会直接导致GC频繁、线程阻塞、结果数据丢失。GUI模式下跑高并发尤其不推荐因为界面渲染和结果监听器会吃掉大量CPU和内存。跑到200以上并发时我强烈建议关掉GUI使用命令行模式。命令行模式的基本姿势是jmeter -n -t test_plan.jmx -l result.jtl -e -o html_report其中-n表示非GUI模式-t指定脚本-l指定结果文件-e和-o表示测试结束后生成HTML聚合报告。跑之前最好显式调整JVM堆参数Windows下修改jmeter.bat、Linux下修改jmeter.sh或者直接通过环境变量传参HEAP-Xms4g -Xmx4g -XX:MaxMetaspaceSize512m jmeter -n -t test_plan.jmx -l result.jtl把初始堆-Xms和最大堆-Xmx设为相等目的是避免JVM反复扩容导致性能抖动。具体设多大取决于你压测机的物理内存和线程数规模4G是一个比较稳妥的起点如果跑1000并发以上我通常直接给到8G。注意堆内存不是越大越好过大反而导致GC单次停顿时间变长。另外GUI模式下添加了大量监听器尤其是“查看结果树”在命令行模式跑的时候这些监听器也会被加载消耗资源。建议在大规模压测时要么把脚本复制一份删掉结果树监听器要么在命令行模式故意只保留简单的监听器最终结果通过生成HTML报告来看。这个经验在压测1000并发时尤其明显删掉结果树之后本机CPU占用能下降至少二十个百分点。4. 两套可直接照抄的并发测试参数配置4.1 场景一订单查询接口5分钟持续压测这是一个非常典型的日常压测需求订单查询接口线上预估峰值并发100需要验证在持续5分钟的稳定压力下系统的平均响应时间和错误率是否满足要求。我用普通线程组就能完成具体参数线程数100Ramp-Up 20秒循环次数勾“永远”调度器勾“持续时间”填300启动延迟留空。HTTP请求里连接超时设3000毫秒响应超时设10000毫秒Keep-Alive保持默认勾选。为什么Ramp-Up设20秒而不是更短因为100个线程如果5秒内全部启动相当于每秒钟新建20个连接服务端的连接池可能来不及释放旧连接导致一部分TCP握手排队。而20秒意味着每秒只新增5个线程压力曲线平缓前20秒是预热阶段后面280秒才是真正的稳态数据。跑完后我会把生成的HTML报告打开主要看三个指标聚合报告里的“平均响应时间”、吞吐量TPS以及错误率。在分析时有个小技巧不能只盯着整个时间段的总平均值因为前20秒的Ramp-Up阶段响应时间偏低会拉低整体均值。我更看重的是测试时间后3分钟的数据也就是稳态段的TPS和响应时间曲线。如果曲线平稳P95响应时间在预期范围内错误率为0那这次压测就算通过如果曲线一路向上倾斜说明很可能存在内存泄漏或连接池耗尽的问题光调JMeter参数已经解决不了。4.2 场景二阶梯加压找系统拐点bzm并发线程组如果目标是找出系统“从哪个并发数开始明显劣化”我会用bzm - Concurrency Thread Group来做阶梯加压。典型配置Target Concurrency300Ramp Up Time150Hold Load Time60Steps5这套配置的实际效果是每30秒增加60个并发150秒分5个阶梯每个阶梯上一档到达300并发后再整体保持60秒。这样一轮压测跑下来能直观看到50、110、170、230、300这几个并发档位下吞吐量和响应时间分别是什么状态。很多系统在并发逐步上升的过程中吞吐量先上升到达一个拐点后开始下降或持平而响应时间则在某个并发点突然抬头。这个“拐点”就是容量评估的核心依据。我见过一个项目200并发时TPS已经基本不涨响应时间反而从500毫秒涨到2秒这种情况下继续把并发加到500毫无意义系统瓶颈已经暴露在数据库连接池而不是接口代码本身。有一点必须提醒bzm并发线程组需要在Plugins Manager里安装插件包。安装完之后确保测试计划里不要同时混合普通线程组和bzm线程组去压同一接口否则两边各自按自己的节奏发压力叠加出来的负载曲线完全不可控分析结果时说不清楚压力到底来自哪边。4.3 怎么看结果判断参数配得对不对压测跑完后第一件事不是看聚合报告的平均值而是打开总览图和响应时间随时间变化曲线。如果整个测试周期里响应时间曲线大致呈“上升—平稳—收尾”的形态说明Ramp-Up和Duration配得合理。如果刚一开始曲线就冲天高多半是Ramp-Up太小或者线程数超出系统容量如果曲线一直缓慢爬升没有平稳段说明测试时长不够或者系统存在持续劣化。我平时还会结合HTTP请求的响应码分布来判断。聚合报告里有“错误率”这一项但很多场景只统计了响应码非2xx/3xx的请求。如果服务端返回200但响应体里是业务错误JMeter默认并不会把它计为错误。所以真正严谨的压测脚本里业务关键接口都会加一个“响应断言”比如断言JSON里的code字段为0。这个操作会让结果更贴近真实业务成功率。没有断言保护的压测哪怕错误率显示0都可能是假象。还有一种快速验证参数是否合理的方式用聚合报告里的“吞吐量”和理论值对比。如果100并发、平均响应时间200毫秒理论最大TPS大约在500左右实际跑到450到500基本说明配置没问题如果实际TPS只有200那不用急着调JMeter应该先检查被测系统的瓶颈在哪里。5. 常见问题与排查技巧实录5.1 错误率飙高第一件事检查什么压测过程中发现错误率突然往上跳我第一件事不是看JMeter日志而是去区分错误类型。结果树或聚合报告里如果大量出现“Connection timed out”优先排查是不是并发线程数起太快导致服务端连接数瞬间爆满如果Ramp-Up本来就是0先把Ramp-Up拉长到合理范围再跑一轮这个问题大概率会缓解。如果错误类型是“Non HTTP response code: java.net.SocketException”也就是连接被重置那就要回头看服务端的连接数和超时配置还有压测机和被测机器之间的防火墙或负载均衡空闲超时。很多中间层设备会把空闲时间过长的TCP连接回收掉而Keep-Alive长连接被回收后再复用就会触发SocketException。遇到这种场景可以适当降低连接空闲时间阈值或者在JMeter的HTTP请求配置里调整连接超时让旧连接及时被替换。如果是“Read timed out”就要回到响应超时的设置逻辑上去。服务端处理变慢压测端超时设置又太苛刻就会出现大量读超时。需要分清楚是服务端真慢了还是压测端设置本身有问题。我的排查路径一般是看服务端监控的CPU、内存、GC日志、数据库慢查询如果服务端各项指标正常再把压测端的超时阈值放宽一点对比错误率的变化。5.2 响应时间越跑越慢先怀疑谁持续压测跑到第3分钟、第5分钟发现响应时间逐渐变长这有两个大方向被测系统的问题和压测自身的问题。被测系统层面常见的是内存缓存被逐步填满后触发频繁GC、数据库连接池耗尽、部分慢SQL堆积压测自身层面则要看JMeter所在机器的CPU、IO是否已经打满结果文件写入是否成为瓶颈。区分方法很简单看压测机的CPU。如果压测机CPU已经接近100%先解决压测端问题。一个非常有效的调整是把“查看结果树”这类监听器从脚本里去掉只保留聚合报告或干脆不加结果写入监听器用命令行模式生成jtl文件后再离线生成报告。我在测试环境压测一个高吞吐接口时只去掉一个结果树监听器压测机CPU从90%掉到60%响应时间曲线立刻平稳下来。如果压测机CPU没问题那问题大概率在被测服务。这是服务端数据库层面的优化工作但有一个策略性建议遇到响应时间劣化先把持续压测停下来把并发降到一半左右跑3分钟看响应时间是否恢复。如果恢复大概率是资源泄漏或连接池问题如果不恢复可能是环境被污染了需要重启被测服务再测。这个二分法能快速定位方向不至于在错误的方向上反复折腾。5.3 压测机CPU打满被测服务却很闲这是分布式压测里常见的怪象被测服务端CPU使用率不到20%压测机这边CPU已经100%吞吐量上不去。原因通常是压测机单机模拟能力到了极限而不是服务端没有余量。解决办法是减少JMeter本机资源开销以及把压力分散到多台压测机上。减少JMeter本机开销的措施按优先级排序删除结果树、简单数据写入器等重资源监听器关闭GUI改用命令行降低不必要的断言数量如果脚本里有大量正则表达式提取器考虑用JSON提取器替代尽量让线程数不要出现巨大波动避免高频线程创建销毁。如果单机优化后依然压不满目标那就上分布式压测。JMeter的分布式模式是Master-Slave架构Master分发脚本到多台SlaveSlave各自产生压力并把结果回传Master。配置要点是把jmeter.properties里的remote_hosts填上所有Slave的IP和端口默认端口是1099。第一次做分布式压测最容易踩的坑是Slave机器上的JDK版本、JMeter版本和Master不一致导致脚本分发后运行报错。所以上线分布式前我会先把所有Slave的JMeter环境统一到完全相同的版本再跑一个小的脚本验证所有Slave都能正常返回结果。还有一个常见问题是Master自身也参与了压测导致本机也不够用。分布式模式下建议Master只负责调度和汇总不跑负载在启动压测时不要勾选“本机运行”相关选项让压力全部由Slave承担。5.4 分布式压测时最容易漏掉的参数配置分布式压测还有一个经典坑脚本里的CSV数据文件。如果脚本里用了CSV Data Set Config来读取测试数据在本地跑一切正常一旦换成分布式模式每个Slave都会尝试读取脚本里配置的CSV路径。如果路径只在Master本机存在或者各Slave上文件的副本内容不一致测试结果就完全不可信了。最稳妥的做法是在每台Slave的完全相同路径下放置完全一致的CSV文件同时把CSV Data Set Config的“文件共享方式”设为“所有线程”或者“所有线程每个线程组”。这样一来每个Slave读到的是同一份完整数据不会出现不同线程组之间重复或漏读的情况。另外一个容易漏配的是JMeter的系统属性参数比如-J指定的自定义变量。本地压测时在命令行里写了-JtargetHostxxx脚本里也通过__P函数引用它但分布式模式下这个参数只传给了Master没有传给Slave。所以在分布式压测里所有需要动态传入的变量要么直接写死在每个Slave的JMeter配置文件里要么通过jmeter.properties里的__P默认值兜底。我在一次跨机压测中遇到过整轮测试都用了默认值跑完才发现的问题事前把每个Slave的变量核对清楚能省下至少一小时的无效测试时间。最后说一个我自己的习惯任何正式压测之前我都会先用5个并发、持续30秒跑一轮冒烟。目的不是拿数据而是确认脚本本身没有语法问题、断言逻辑正确、结果文件路径可写、服务端没有因为权限问题返回500。很多人在并发参数上反复打磨结果连脚本跑不通都没发现白白浪费大量时间。JMeter并发测试核心参数配置这件事本质上就是把“模拟多少用户”“多长时间内启动”“持续多久”这三件事想清楚剩下的就是不断压、不断看曲线、不断修正模型。参数永远是为验证目标服务的别为了调参而调参。
阅读完成 · 觉得有帮助？
