前两周接到一个活动压测需求业务方给的需求描述很简洁一万名用户同时请求两个活动接口两个接口存在串联关系第二个接口用到了第一个接口的返回结果。这种场景在jmeter接口压测里相当典型接口串联加参数关联看起来也就是“先请求A从响应里取个值再拼到B上”这么简单。但真正动手压的时候问题一个接一个一万并发到底应该怎么建模变量为什么偶尔取到null聚合报告全绿业务方却跟我说数据对不上这篇文章我就把这类串联接口的万人压测场景完整拆开从目标拆解、脚本设计、参数关联、结果监控到实战踩坑逐一讲清楚。无论你是刚开始用jmeter写接口脚本还是已经写过一阵子但没正经压过高并发的同学这篇都值得你花十分钟看完至少可以帮你少走我踩过的那些弯路。1. 串联接口压测的目标拆解从“一万人同时请求”到TPS估算1.1 用具体业务例子理解两个接口的串联关系我先拿一个很常见的活动业务举例。接口A是“用户签到领取活动资格”接口B是“使用活动资格参与抽奖”。用户先请求AA返回一个活动token、一个用户标识还有可能返回这个用户可以抽几次奖然后用户带着这个token再去请求BB校验token有效后执行抽奖逻辑返回奖品结果。这个业务模型里有两个关键点第一两个接口是顺序依赖的B必须依赖A的响应数据才能发起第二A和B的业务性质不同A一般是轻量的写操作B往往涉及库存扣减、奖品池选取、幂等校验性能开销比A大不少。在压测的时候如果只盯着B的TPS忽略A的响应速度对B的影响很容易得出一个“上线后立刻被打爆”的结论。所以拆解需求的第一步不是急着打开jmeter而是要把这个链路涉及的接口、入参、返回、下游依赖全部列出来。我这里列一个通用的字段表你拿到自己的接口后可以照着填接口入参来源响应中需要提取的字段下游依赖接口A签到/领取资格用户ID、活动ID、渠道token、uid、剩余次数用户服务、活动资格库接口B抽奖/核销token、uid、请求流水号奖品ID、优惠券编码、错误码抽奖引擎、库存服务、消息队列把这张表填完你其实就已经把“两个接口存在串联关系”这件事从业务语言翻译成了技术语言后面写jmeter脚本时每一步要干什么都非常明确。1.2 从“一万用户同时请求”推导压测指标业务方说“一万名用户同时请求”这里的“同时”在性能测试里其实很模糊。它可能是真的一万用户在同一秒发起请求也可能是一万用户在线各自在几分钟内陆续操作几次。这两个模型算出来的TPS差了数十倍压测方案完全不一样。我一般这样估算如果一万用户集中在1分钟内完成一次操作那么平均TPS就是 10000 / 60约等于167如果集中在10秒内全部涌入TPS就是1000如果是秒杀场景一万用户在同一秒打进来那入口的瞬时TPS就要按一万甚至更高去设计因为还有重试请求叠加。回到jmeter接口压测场景里这个估算决定了你的线程组规模。注意jmeter里的线程数不等于TPS。一个线程可以持续发请求它的实际TPS取决于接口响应时间。比如接口平均响应是200毫秒那么一个线程稳定状态下大概能跑5 TPS如果你想让整个链路达到1000 TPS理想情况下需要200个线程左右。如果要求一万用户同时完成一次操作且规定在10秒内全部完成那目标TPS是1000用200到300个线程加循环次数就可以模拟出来而不是真的开一万个线程。1.3 阶梯加压是串联接口压测的默认姿势我见过不少新人拿到“一万并发”就立刻在线程组里填10000然后直接点击运行结果压测机自己先卡死了。这不是jmeter不行而是你一口气把压力全怼上去根本分不清系统是在哪个负载点开始劣化的。正确的姿势永远是阶梯加压。先用少量线程验证脚本正确性比如10个线程跑两分钟确认参数关联成功、断言通过然后逐步增加线程数比如按200、500、1000、2000这样的梯度往上加。每个梯度跑3到5分钟观察TPS曲线、响应时间曲线和错误率变化找到系统的拐点。为什么串联接口更需要阶梯加压因为第二个接口依赖第一个接口的返回结果一旦第一个接口在压力升高后出现超时或失败第二个接口会成片失败错误率曲线会非常难看。这时候你如果是一次性怼到一万根本看不出来是A先扛不住了还是B本身就扛不住。阶梯加压能让你清晰看到先崩的到底是链路里的哪一个环节这个信息对开发和运维定位问题极其重要。2. 参数关联实现把第一个接口的返回结果安全地传给第二个接口2.1 优先用JSON Extractor而不是正则串联接口压测最核心的技术点就是参数关联。现在绝大多数HTTP接口都返回JSON所以我的第一选择是JMeter的JSON Extractor后置处理器它的配置非常直观而且不会像正则那样容易匹配错。举个例子接口A返回下面的响应体{ code: 0, message: success, data: { token: a1b2c3d4e5, uid: 10086, remainingTimes: 3 } }接口B的请求头里要带token请求体里要带uid。在接口A这个取样器上右键添加“后置处理器 - JSON Extractor”分别配置两个变量配置项变量token变量uidName of created variablestokenuidJSON Path expressions$.data.token$.data.uidDefault valuesNOT_FOUNDNOT_FOUNDMatch No.00这样在同一个线程组的后续取样器里直接写${token}和${uid}就能引用到。在HTTP Header Manager里把token加到请求头在HTTP请求的Body Data里写{uid: ${uid}}之类的JSON就可以完成参数传递。2.2 什么时候才需要用正则表达式提取器JSON Extractor虽然好用但也有它搞不定的情况。比如接口A返回的不是JSON而是一段HTML页面或者返回体里混了一段模板字符串再或者你对接的老系统接口返回格式是token:xxx;expire:yyy这种自描述格式这时候就需要正则表达式提取器。正则提取器的核心就一个写好匹配表达式。比如返回体里有token:a1b2c3d4e5那正则就写token:(.*?)模板写$1$。注意正则里的.*?是非贪婪匹配如果写成了.*在遇到多个字段时它会尽可能多地吞内容轻则提出来一段垃圾数据重则直接导致后续请求全部失败。我的习惯是同事之间维护的接口优先用JSON Extractor因为可读性强只有遇到非JSON响应才用正则而且每次配完正则都会加一个调试取样器验证防止匹配范围错了。2.3 关联变量作用域和时序为什么有时候取到null这是串联接口压测里最容易翻车的地方没有之一。很多同学把JSON Extractor放在了线程组下面而不是接口A取样器下面然后第二个接口里的${token}就变成了Default value里配的NOT_FOUND。原因是作用域搞错了。后置处理器只有放在某一个取样器下面或者放在某个逻辑控制器下面且该控制器包含这个取样器时它才会在这个取样器执行完成后立即运行。如果放在线程组下面它确实也会运行但执行顺序可能是在所有取样器开始前此时接口A还没有被调用自然提取不到任何数据。另外一个常见问题是线程间变量覆盖。JMeter里同一个线程组下每个虚拟用户是独立的线程变量是线程隔离的所以A线程的token和B线程的token不会互相覆盖。这一点可以放心不用担心并发下变量串了。但如果你把token存成了JMeter属性比如用${__setProperty(token,${token})}那就是全局共享了一万个线程会互相覆盖第二个接口拿到的token大概率不是当前用户自己的。所以参数关联的正确姿势就是把提取器放在接口A下面每个线程在自己内部完成“请求A - 提取变量 - 请求B”的闭环。2.4 用Debug PostProcessor验证变量值脚本刚写完时不要急着压测先在接口A和接口B之间加一个Debug PostProcessor运行一遍后用View Results Tree查看它输出的变量列表。Debug PostProcessor会把这个线程当前作用域内所有变量都打印出来一眼就能看出token和uid有没有正确提取到。有一次我排查一个串联接口的问题接口A返回的JSON里其实有两个token字段一个在data里一个在扩展信息里JSON Path表达式$.data.token没问题但正则表达式token:(.*?)就匹配到了第一个token导致接口B一直报token不存在。如果没有Debug PostProcessor这个问题可能要等到压测结束后拿日志对账才能发现。3. 线程组设计一万虚拟用户到底要怎么给JMeter配置3.1 直接用10000线程的后果是什么回到标题里的场景一万名用户同时请求。很多人的第一反应就是把线程数设成10000循环次数改成1感觉这样就是“一万并发”了。在实际压测中我不建议直接这么做原因有三个。第一每个JMeter线程在压测机上都要占用内存和CPU默认的JVM堆内存如果没调大开几千个线程后压测机自己就先频繁GC了结果根本测不准第二一万个线程同时启动对被测系统的冲击不是平滑的而是一瞬间打满这个压力模型不一定符合真实业务第三你无法定位瓶颈系统崩溃了你都不知道是A接口的线程池先满了还是B接口的数据库连接池先满了。早年我用8G内存的笔记本压测开了3000个线程直接卡死后来改用命令行模式加调大堆内存才稳定下来。所以线程数这个东西不是想开多少就开多少。3.2 更科学的配置线程数、Ramp-Up和循环次数的配合我的习惯是把“一万用户同时请求”拆解成“一段持续时间内每秒产生多少请求”然后用吞吐量整形定时器Throughput Shaping Timer或者阶梯线程组来控制。如果你用的是普通线程组至少要做好下面三个参数的配合参数我的设置建议说明Number of Threads(users)500~2000虚拟用户数不是TPS具体按目标TPS和响应时间反推Ramp-up Period(seconds)60~180让用户逐步启动避免瞬时冲击也便于观察性能拐点Loop Count根据目标TPS计算每个用户循环多次比开上万个线程要省资源得多举个例子目标TPS是1000接口平均响应时间是200ms每个线程稳定能跑5 TPS那200个线程就够了。线程数设为200Ramp-Up设成60秒循环次数设成50这样每个用户会连续执行50轮“A - B”串联请求总请求量是200×50×220000个足够压出稳定的TPS数据。可能有人会问这样不是“一万个用户”了。你要理解jmeter的虚拟用户只是一个并发执行单元它能发起多少请求取决于压测时长和接口响应速度。压测的目的是验证系统承载能力不是死抠用户总数这个数字。3.3 两个串联接口应该放在同一个线程组还是分开两个线程组这是一个非常关键的设计决策。我见过有人把接口A和接口B分别放在两个线程组里然后试图通过${__P()}传参数结果就是前面说过的全局共享问题线程间数据互相污染压测出来一片混乱。串联接口的正确做法是放在同一个线程组并且按顺序添加Thread Group下面先放接口A的HTTP请求再放接口A的JSON Extractor然后放接口B的HTTP请求。JMeter默认按取样器在树中的顺序执行所以同一个线程内一定是A先执行完提取器提取到变量B再带上变量发起请求。这个顺序天然就是对的不需要额外加同步控制。只有在一种情况下考虑分开线程组就是两个接口的业务节奏完全不同比如A接口是每秒固定频率被调用B接口是突发性调用且两者之间通过消息队列解耦。但这时候它们本质上已经不是串联接口了而是异步链路压测模型要另外设计。3.4 加压机和配置对万人压测的影响如果你所在的公司压测环境里有条件用两台以上的压测机一万并发时建议做分布式压测。单台jmeter在GUI模式下跑高并发是自找麻烦要压就切成命令行模式jmeter -n -t activity_test.jmx -l result.jtl -j test.log -e -o report/这条命令会以非GUI模式运行脚本将结果写入jtl文件并自动生成HTML报告。命令行模式比GUI模式省下大量渲染开销能多撑不少并发。内存参数也不能忽略。jmeter默认的堆内存是1G左右高并发时明显不够。打开jmeter目录下的jmeter.bat或jmeter.sh找到HEAP配置项改成-Xms4g -Xmx4g -Xmn2g这类大小具体根据压测机内存调整。4. 断言与监控压测结果不能只看HTTP 2004.1 响应断言要校验业务字段而不是只查状态码这是压测脚本里我吃过亏的地方。一开始我压接口只加了HTTP状态码断言响应200就算通过。结果压完一看错误率0%非常漂亮但业务方拿着数据库流水说抽奖成功的记录数少了三分之一。原因是服务端遇到限流、参数校验失败、库存不足这些情况时HTTP状态码照样返回200只是在响应体里放了一个非零的code或者把message改成了“活动已结束”。jmeter不知道你的业务规则它只看到200就觉得请求成功了。所以串联接口的每个请求都要加业务断言。接口A可以断言响应体里包含code: 0同时包含预期的token字段接口B可以断言响应体里包含code: 0如果抽奖结果里固定有奖品ID字段也一并断言。用JMeter原生的Response Assertion就能做勾选“响应文本”或“响应消息”再填上要匹配的字符串。更精确一点可以装一个JSON Assertion插件用JSONPath直接断言$.code 0这样即使响应体格式发生变化断言逻辑也更稳。4.2 聚合报告和性能指标怎么解读压测结束后最常用的报告是聚合报告Aggregate Report和HTML报告。你不用把每个指标都背下来但下面这几个一定要会看指标含义经验参考值Samples样本数越大越有统计意义至少跑几千个Average平均响应时间看业务要求一般小于500ms可接受Median中位数响应时间比平均值更抗噪建议作为主要参考90% Line / 95% Line / 99% Line高百分位响应时间在线系统的尾延迟比平均值重要得多Throughput吞吐量单位通常是/sec这就是实际的TPSError %错误率业务稳定性要求高的话应低于0.1%很多同学只盯着平均响应时间看到平均200ms就觉得系统很好。实际上如果99% Line是2秒说明有1%的用户体验非常差在万人压测背景下1%就是100个用户这已经是很严重的体验问题了。另外注意串联接口的两个请求在聚合报告里是分开统计的。你要把接口A和接口B的样本分开看尤其是接口B因为它的数据依赖A的响应结果。如果A的响应变慢B的请求实际上是滞后于A的体现在聚合报告里就是B的平均响应时间在压测后期快速上涨而A还很平稳这就说明A到B之间的关联链路存在瓶颈。4.3 服务端监控压测机之外的数据更能说明问题jmeter只能告诉你“客户端视角的系统表现”它没法告诉你服务端到底是CPU打满了、内存吃紧了还是数据库连接池满了。所以压测的时候一定要同时采集服务端指标。如果是Java后端至少要看JVM的GC频率、堆内存使用量、活跃线程数如果是部署在Linux上用top、vmstat、pidstat这些命令看CPU和上下文切换数据库方面看连接数、慢查询数、锁等待。云平台上一般自带监控面板压测前先把监控图截图保存压测后再拉取同一时间段的监控数据进行对比。判断瓶颈在哪有个比较实用的经验当并发上去后如果吞吐量不再上升而响应时间持续上涨大概率是某一层资源被打满了。这时候去服务端看CPU如果接近100%那就是计算密集型瓶颈如果CPU不高但数据库连接池拿不到连接那就是下游存储瓶颈如果一切指标都正常但TPS就是上不去要考虑是不是压测机本身的带宽或连接数到了上限。5. 带着参数关联做万人并发我踩过的5个坑和排查思路5.1 变量提取失败但脚本“看起来”在跑有一次我压测串联接口接口A的取样器显示绿色接口B也显示绿色但聚合报告里错误率始终在5%左右。我去翻接口B的请求体发现uid字段全部是NOT_FOUND而token字段反而是正常的。排查过程是这样的先看接口A的响应确认返回体里确实有uid字段再看JSON Extractor的配置发现我在同一个JSON Extractor里配置了两个变量但JSON Path表达式第二行写错了写成了$.data.userId而响应体里的字段名是uid。JSON Extractor提取不到值时不会报错它只会往变量里填Default value而接口B拿着这个默认值去请求服务端返回了业务错误但HTTP状态码还是200。这个坑说明两个问题第一脚本跑通不等于脚本正确必须依赖业务断言和变量验证第二多个字段的提取最好拆成多个JSON Extractor或者配好后用Debug PostProcessor全部打印出来检查一遍。5.2 全局属性传参导致一万个线程数据互相串还有一种情况我在同事的脚本里见过他把token提取出来后用${__setProperty(token, ${token}, true)}存成了JMeter属性然后在接口B的请求头里用${__P(token,)}读取。这样做的本意是“把A的返回结果传给B”但完全忽略了线程隔离的问题。JMeter的属性和变量的区别在这里体现得非常明显变量是每个线程独立的属性是全局共享的。一万个线程并发执行时线程1刚把token1写入属性线程2立刻就把token2覆盖进去等到线程1的接口B去读取拿到的是token2甚至token10086。结果是接口B大部分请求都带着别人的token轻则业务校验失败重则可能拿到别的用户的数据。这类错误之所以隐蔽是因为它不是每次都错而是随机错。压力小时并发线程不多覆盖频率低错误率可能只有1%以下不容易引起注意压力一大错误率直接飙升。排查手段是看jmeter日志里的请求参数如果发现同一个token被大量不同线程使用基本就是全局属性串数据了。解决办法就是把所有需要跨接口传递的数据都保持在变量层面不要用属性。5.3 HTTP KeepAlive和高并发下的连接资源串联接口压测时接口A和接口B都走HTTP连接。默认情况下JMeter会开启KeepAlive复用一个连接发送多个请求这对压测机的资源利用是好的。但如果你的被测系统限制了单连接并发数或者服务端配了短连接策略KeepAlive反而可能导致连接排队响应时间异常升高。我在压测一个老系统时遇到过这类问题压测机上显示的连接数堆积严重服务端大量socket处于TIME_WAIT状态TPS上不去。排查后发现是服务端网关关闭了KeepAlive每次请求都新建连接高并发下也没有连接池复用最终把端口资源耗尽。这种情况下的调整方向有两个一是压测脚本里勾选KeepAlive并确认被测服务支持二是如果被测服务明确是短连接就要提前考虑系统层面的socket参数优化比如放大约束临时端口范围、调整TIME_WAIT回收参数。这些内容在压测前就要跟服务端团队确认不要等到压测开始后才发现。5.4 循环内变量更新与业务状态冲突串联接口在一个循环里反复执行时每次循环都会重新请求接口A然后重新提取token。但业务系统通常对token有有效期和有效期次数限制比如一个token只能用一次或者只能抽奖一次。如果你的脚本让同一个虚拟用户循环30次每次都领取新token再抽奖第二次循环时接口A可能因为“用户已领取过资格”而失败接口B拿不到新token就报错。这不是脚本写错了而是测试数据和业务逻辑本身冲突。解决办法是准备足够多的测试用户每个用户只执行一轮或有限几次循环。比如你有一万个测试账号就把线程数设成10000循环次数设为1这样每个账号只领取一次资格、抽一次奖业务上完全走得通。准备大量测试数据也是串联接口压测里逃不掉的工作。一万个账号、每个账号的初始状态干净这需要开发配合造数。如果数据量不够就硬压最后压的不是系统性能而是数据冲突的错误率。5.5 花大量时间调脚本不如先做一轮小并发完整走查最后这个坑可能更像经验总结。我在做万人压测之前习惯先花15分钟用10个线程、循环1次把整个脚本完整跑一遍然后逐个检查接口A的响应、变量提取结果、接口B的请求参数和断言结果。这轮走查通过后再用100个线程跑3分钟确认TPS基线正常。只有这些前置步骤都做完了我才会开500、1000、2000这样的大并发阶梯去压真实场景。有的人觉得前置步骤浪费时间上来就想直接压一万并发。但根据我的经验90%的串联接口脚本问题在前两轮小并发走查时就会暴露出来根本不需要等到大并发阶段才满头大汗地排查。小并发跑一遍成本可能只有一两分钟却能省下压测过程里数个小时的定位时间。说到压测结果的最终判断我个人现在的标准很简单接口A和接口B的错误率都低于0.1%PC端核心操作的99%响应时间在1秒以内服务端CPU和内存没有长时间处于90%以上的饱和状态同时吞吐量曲线在压测后半段保持平稳没有明显掉坑。在这个标准之下再结合业务方对“一万用户同时请求”的模型定义去反向核对TPS是否达标。实际情况里任何一个环节不满足我都会要求先做优化再重新压一轮而不是拿一份“看起来很热闹”的聚合报告去交差。
