1. 一个再常见不过的场景为什么单独看接口耗时压测结果还是不对前两天有个做后台开发的朋友拿了一份压测报告来找我说他们的接口平均响应时间都在200毫秒以内TPS也很高可用户总反馈说操作很卡。我看了半天问了一句你压的是单个接口还是用户从点击到出结果的完整流程他愣了一下说当然是每个接口分别压啊。问题就出在这里。JMeter里要模拟一个完整业务流程的耗时最直接的工具就是事务控制器Transaction Controller它会把你指定的多个请求合并成一个整体来统计时间。没用好它你的压测数据基本只能证明“接口没问题”证明不了“业务没问题”。很多刚接触性能测试的人容易陷入一个误区接口快就代表系统快。实际上用户感知到的是完整操作链路的响应时间比如登录后马上查询订单、查询库存、提交支付这一串动作做完用户才觉得“不卡了”。如果每个接口都是200毫秒但中间有页面解析、报文组装、请求排队用户实际等待可能要1秒以上。如果你没有用事务控制器把整条链路包起来这些额外开销就完全不会出现在报告里。1.1 你面前这份“接口全部正常”的压测报告我让这位朋友把之前的报告发过来数据确实漂亮接口平均响应时间90%响应时间TPS登录135ms210ms120查库存89ms140ms150下单215ms330ms98模拟支付340ms520ms72单看每个接口都没毛病支付接口稍微慢一点但也没到告警线。可问题恰恰出在这里压测脚本是四个接口分开跑每个线程组各压各的报告里根本没有“一次完整下单要花多久”这个数字。真实用户的操作顺序是登录、查库存、下单、支付这四个动作串起来的实际耗时跟四个接口单独的平均耗时完全不是一回事。前者是在一个线程内连续执行的完整事务后者是四个独立线程各自跑出来的统计样本。你要压测的目标如果是“每秒能处理多少笔完整下单”那就必须把四个请求放在同一个事务里让JMeter统计从第一个请求发起到最后一个请求结束的完整时长。这才是用户视角的响应时间。1.2 用事务控制器重新审视一次真实下单流程事务控制器的核心作用可以概括成一句话把一组采样器打包成一个整体在聚合报告里生成一条独立记录这条记录的时间就是整组采样器从开始到结束的跨距。它不是简单地把几个接口的响应时间加起来而是像一个秒表在第一个子请求发出前按下开始在最后一个子请求返回后按下停止。所以事务时间天然包含了请求之间的间隙、变量处理时间、断言执行时间以及可能的思考时间。对于“用户的完整操作要多久”这个问题事务控制器给出的答案比任何单个接口的统计都更接近真实体验。我在实际项目里通常把事务控制器用在两类地方一类是核心业务流程比如“登录查询商品加购物车提交订单”这种必须串行完成的操作另一类是接口间有强依赖的场景比如先获取Token再调用业务接口你把两个步骤包进同一个事务报告里看到的才是“一次带鉴权的调用”的真实耗时。明白了这个定位后面的配置才不至于用歪。2. 事务控制器的基本配置与关键选项照着填就行了事务控制器的添加方式很简单在测试计划里选中线程组右键选择“添加 - 逻辑控制器 - 事务控制器Transaction Controller”。面板上有两个选项一个叫“Generate parent sample”一个叫“Include duration of timer and pre-post processors in generated sample”。这两个选项直接决定你的报告长什么样、时间算的是什么很多人在这一步就填错了。2.1 在测试计划里加一个事务控制器不需要任何依赖包JMeter自带。添加之后建议立刻给它改一个可读的名字比如“TC_登录后查询_完整链路”千万别叫“事务控制器”。因为后面报告里显示的就是这个名字命名太随意会导致你看图表时还要一个个回忆是哪个流程。命名规则我一般用“TC_业务场景_说明”跟普通HTTP请求区分开。事务控制器本身不发送任何请求它只是容器所以你把它拖到线程组下面后还要把要合并的HTTP请求、JDBC请求、或者其它采样器拖进去。层级结构大概是线程组 └── 事务控制器 TC_登录后查询 ├── HTTP请求-登录 ├── HTTP请求-查询用户信息 └── HTTP请求-查询订单列表有一点要注意事务控制器里的采样器是严格按顺序执行的从前到后一个个跑。如果你希望某些请求并行发出单靠一个事务控制器做不到需要配合并行控制器或者自己用线程实现。大多数业务流程是串行的所以一般情况下直接顺序执行没问题。2.2 Generate parent sample用还是不用这决定了报告长什么样这个选项默认不勾选。不勾选时聚合报告里既能看到“登录”“查询用户信息”“查询订单列表”这几个单独的行也能看到“TC_登录后查询”这个事务行。勾选之后事务控制器会把自己伪装成一个父采样器子采样器全部变成它的子结果聚合报告、Summary Report这类监听器里只会显示“TC_登录后查询”这一行子请求不再单独出现。两种模式各有用途。如果你压测的目标是分析每个子步骤的耗时那就别勾选保留子请求的明细。如果你的目标是给出一个完整业务链路的综合指标那建议勾上报告会干净很多领导看起来也直观。提示勾选Generate parent sample后查看结果树里仍然能看到子采样器只是层级变了一层通常显示在事务节点下面。这一点不影响你调试脚本但会影响你给报告截图时的观感提前知道比较好。我自己的习惯是调试阶段不勾选方便在查看结果树里逐个看请求正式压测阶段勾选让聚合报告只输出事务级别的结果。2.3 Include duration of timer and pre-post processors思考时间算不算进去这个选项是JMeter 4.0之后才有的默认不勾选。它的含义是事务统计的时间里要不要包含定时器、前置处理器、后置处理器消耗的时间。很多人在这里吃亏。场景是这样的你在事务里放了三个HTTP请求为了让压测更接近真实用户在请求之间加了Constant Timer每个思考时间1秒。如果不勾选这个选项事务时间只统计三个请求本身的响应时间三个思考时间不会算进去。勾选之后两个1秒的思考时间也会被算进总事务时间事务平均响应时间一下子多出2秒。到底勾不勾取决于你的压测目标。如果你要评估的是系统处理能力比如“接口本身每秒能扛多少请求”那思考时间不应该算进去保持默认不勾选。如果你要评估的是用户体验比如“一个真实用户从下单到支付完成要等多久”那思考时间是有意义的应该勾上。注意如果你用的JMeter版本低于4.0面板上根本没有这个选项定时器的时间会直接算进事务时间。遇到这种情况最好先升级JMeter否则统计口径和别人的报告对不上。3. 事务控制器的时间统计逻辑从源码层面彻底讲清楚配置界面只是表象真正决定你报告数据准不准的是事务控制器内部的时间统计方式。理解了这个你就能解释很多奇怪的现象为什么事务时间比子请求加起来还长为什么某个子请求没执行事务却依然有数据为什么事务会失败3.1 它统计的不是“加总”而是“跨距”事务控制器的底层实现里TransactionSampler会在进入采样器集合的时候记录一个startTime在最后一个子采样器执行结束后记录endTime事务响应时间就是endTime减去startTime。所以它统计的是整段时间跨度而不是子请求耗时的累加。举个例子登录请求耗时300毫秒查询订单耗时500毫秒这两个都是采样器自身的统计口径。把它们放进同一个事务控制器登录请求返回后、查询订单发出去之前JMeter还要做变量处理、断言校验、监听器回调这些操作可能要几十毫秒。事务时间统计的就是“登录开始那一毫秒”到“查询订单结束那一毫秒”的全部时间。登录请求开始 登录请求结束 |---------- 300ms ----------| |---变量处理---|---------- 500ms ----------| 事务时间跨度约850ms而不是简单相加的800ms这解释了为什么事务时间总是大于等于子请求时间之和。如果你发现事务时间比子请求之和多出一大截先看看事务里是不是有定时器、是不是有前后置处理器在做耗时操作再考虑要不要勾选Include duration。3.2 子采样器不执行时事务时间怎么算事务控制器支持嵌套If Controller、Loop Controller这类逻辑控制器。也就是说事务里的子采样器不一定会全部执行可能某些循环下部分请求被跳过。这种情况下事务的时间跨距只计算那些“实际执行了”的子采样器。如果三个子请求里有一个因为条件不满足被跳过事务时间就是另外两个请求从开始到结束的跨距。还有个边界情况如果所有子采样器都没有执行事务控制器就不会生成采样结果聚合报告里这一行可能压根不出现。我实测过把If控制器条件设成永远为假后事务在聚合报告里就消失了。所以写脚本时要注意别把事务放在一个可能永不执行的条件分支里否则压测结束你发现事务数据是空的还要回过来排查半天。3.3 一个容易误读的细节断言失败与事务失败判定事务控制器本身没有断言功能它的成功失败取决于子采样器。只要有一个子采样器返回失败或者子采样器上的断言失败事务整体就会标记为失败。但注意JMeter默认不会因为某个子采样器失败就停止后续请求事务里的剩余请求照样执行事务时间照常统计。这个特性在实际压测中非常容易误导人。比如登录失败后查询订单大概率也会失败但事务控制器还是会跑完全部请求最后显示失败。你在聚合报告里看到事务失败率很高点进查看结果树一看其实是登录接口的Token没拿到后面所有请求都在打空请求。所以我的建议是事务控制器里的关键步骤一定要加断言尤其是那些会影响后续请求的步骤比如登录、获取Token。这样失败原因一目了然。不加断言的话事务失败只能说明“某个环节挂了”但挂在哪一步你得自己猜。4. 实战模拟登录后5个线程同时跑查询接口把登录查询做成一个事务下面用一个很典型的场景来走一遍完整配置模拟登录后5个线程同时跑查询接口。这个需求经常出现在“用户登录后并发查数据”的性能验证里正好可以用事务控制器把“登录查询”打包成一个业务操作看系统每秒能完成多少次完整的“登录后查询”。4.1 完整测试计划结构测试计划结构如下测试计划 └── 线程组5个线程Ramp-Up Period0循环次数1 ├── CSV Data Set Config读取用户数据 ├── HTTP请求-登录接口 ├── JSON提取器提取token ├── 事务控制器 TC_登录后查询 │ ├── HTTP请求-查询用户资料 │ ├── HTTP请求-查询订单列表 │ └── HTTP请求-查询优惠券 ├── 查看结果树 └── 聚合报告线程组的线程数填5Ramp-Up Period填0循环次数填1。Ramp-Up Period设为0意味着5个线程会在测试开始后尽快启动基本可以认为是“同时跑”。如果你把Ramp-Up Period设成10秒那5个线程是分散启动的不能叫同时所以这个参数在并发测试里很关键。登录请求放在事务控制器外面还是放在里面两种做法都可以但统计口径不同。把登录放进事务控制器事务时间就包含登录耗时把登录放在外面事务只统计查询接口的耗时。真实用户场景里登录和查询是连续操作建议都放进去这样事务时间才代表“一次完整操作”。4.2 用CSV参数化用户数据登录后提取token到全局变量5个线程不能共用同一个用户登录否则会被系统判定为重复登录甚至触发风控。所以需要一个CSV文件里面放5组用户名和密码。CSV Data Set Config的配置Filename: /path/to/users.csv Variable Names: username,password Delimiter: , Recycle on EOF: True Stop thread on EOF: False Sharing Mode: All threadsusers.csv内容格式user001,pass001 user002,pass002 user003,pass003 user004,pass004 user005,pass005登录接口的请求体里直接用变量引用{username:${username},password:${password}}。登录响应通常是JSON格式比如{code:0,data:{token:abc123}}。右键登录请求添加“后置处理器 - JSON提取器”配置Variable Names: token JSON Path Expression: $.data.token Match Numbers: 1 Default Value: TOKEN_NOT_FOUND这里要注意一个问题JSON提取器提取出来的变量是当前线程的局部变量不是真正的全局变量。事务控制器里的查询请求跟登录请求在同一个线程内顺序执行所以直接用${token}引用就行了。如果你需要跨线程组使用这个token那才需要用__setProperty配合${__P()}但在这个5线程同时跑的并发场景里局部变量完全够用。4.3 事务控制器内部的查询请求设计事务控制器TC_登录后查询下面放三个HTTP请求。每个请求都要用上登录提取的token通常放在请求头里。比如查询订单列表请求头Authorization: Bearer ${token} Content-Type: application/json这里要特别提醒查询请求里如果引用了${token}但是登录请求执行失败导致token没提取到JSON提取器会使用默认值TOKEN_NOT_FOUND查询请求照样会发出去只是返回401。这正是前面说的“事务失败但请求还在跑”的典型场景。如果你希望token提取失败时直接停止整个事务可以在JSON提取器后面加一个JSR223断言或者使用Flow Control Action。不过更简单的做法是给登录请求加一个响应断言检查返回的code字段是0断言失败后事务就会标记失败你就能在查看结果树里快速定位。查询请求之间没有依赖关系所以顺序不重要但事务控制器是串行执行的三个查询接口会一个个跑。如果用户真实操作是同时打开三个页面查询那事务时间就会比真实情况长。这个偏差在性能测试里通常可以接受但你心里得清楚。4.4 跑出数据后在聚合报告里看哪些指标执行完压测后聚合报告里会看到事务控制器的数据行Label显示为“TC_登录后查询”。因为没勾选Generate parent sample所以下面还有登录、查询用户资料等子请求的行。如果你勾选了整个报告就只剩事务这一行和线程组其它非事务请求。关注这几个指标Average事务平均响应时间表示一次完整“登录三个查询”的平均耗时。Throughput每秒完成多少个完整事务。比如TPS是2.5表示系统每秒能处理2.5个完整流程。Error %事务失败率。90% Line90%的事务响应时间在多少毫秒以内这个比平均值更接近用户的真实感受。如果事务平均响应时间明显高于子请求之和回头检查一下事务里是不是有定时器、有没有比较耗时的断言特别是JSR223断言。JSR223脚本如果用了Groovy且没有做缓存每个请求执行前都会编译一次几十毫秒就没了累积起来非常可观。5. 事务数据如何进入压测报告以及InfluxDB/Grafana配合方案很多JMeter使用者只盯着界面里的聚合报告看实际在持续压测或监控场景里事务数据更重要的出口是InfluxDB加Grafana。把事务数据实时推上去你才能在压测过程中随时看到事务响应时间的变化趋势而不是等压测跑完再看静态报告。5.1 聚合报告和HTML报告里的事务行聚合报告里事务行和普通请求行是混在一起的通过Label区分。HTML报告生成时Transactions部分会单独展示事务统计包含Throughput、Response Time等指标。如果你在压测脚本里用了事务控制器生成的HTML报告里会有明显的transaction相关图表这是JMeter自带的能力不需要额外配置。需要注意的是如果你没勾选Generate parent sampleHTML报告的“Transactions”部分可能只会显示数据量级较小的事务行子请求则出现在“HTTP requests”部分。如果你想突出展示完整业务链路而不是每个接口的琐碎统计生成报告前务必勾上这个选项。5.2 用后端监听器把事务数据推到InfluxDBJMeter自带的后端监听器可以实时把采样数据发送到InfluxDB。添加方式线程组右键 - 添加 - 监听器 - 后端监听器Backend Listener。在实现类里选择org.apache.jmeter.visualizers.backend.influxdb.InfluxdbBackendListenerClient。关键参数配置如下influxdbUrl: http://localhost:8086/write?dbjmeter application: my_app_perf_test measurement: influxdb summaryOnly: false samplersList: TC_.*samplersList这个参数很实用它控制哪些采样器会上报。如果你只关心事务控制器的数据可以填TC_.*这样普通HTTP请求不上报InfluxDB里只存事务数据图表干净很多。如果不填默认所有采样器都会上报。事务控制器的名字会作为一个标签tag写入InfluxDB字段名通常是transaction。比如你的事务叫TC_登录后查询在InfluxDB里这条数据的transaction标签就是这个值。5.3 在Grafana里怎么配置事务面板InfluxDB数据源接入Grafana后可以查询事务响应时间的时序数据。最常用的查询是按transaction标签过滤SELECT mean(count) FROM jmeter WHERE (application ~ /^$app$/ AND transaction ~ /^$transaction$/) AND $timeFilter GROUP BY time($interval)更常用的是响应时间和吞吐量面板分别查询min、max、mean字段。如果你压测脚本里的事务命名规范比如统一固定前缀TC_在Grafana的模板变量里加一个transaction过滤器就能在前台动态切换查看不同事务的数据排查问题时非常方便。这里有个实操经验InfluxDB存储的数据量会随着压测时长快速增长如果压测时间很长建议设置合理的保留策略比如只保留7天的数据避免磁盘被写满。别等到压测完想回看数据时才发现InfluxDB已经写爆了。6. 我在事务控制器上踩过的几个坑能躲就躲最后聊几个我在实际项目中踩过的坑。这些坑都不是什么高深问题但每一个都让我浪费过不少时间写出来帮你提前避雷。6.1 用事务控制器统计单个请求的耗时多绕了一圈有人会把一个HTTP请求单独放在事务控制器里说这样“方便统一看事务指标”。这完全没必要。单个请求的耗时HTTP请求自己的采样数据就足够了再套一层事务控制器只是给报告增加行数没有任何额外信息。事务控制器的价值在于“合并多个请求”单个请求的场景别用它。如果你发现自己创建的每个事务控制器下都只有一个子请求那大概率是设计有问题回头看看是不是没把完整链路放进去。6.2 勾了Include duration之后事务时间突然飙高有次接手一个别人的脚本登录查询下单一共三个请求中间每个都加了1秒的思考时间。压测结果事务平均响应时间达到了4.2秒怎么看都不对。排查了半天发现是事务控制器上勾了Include duration of timer and pre-post processors两个Constant Timer的2秒被算进了事务时间。这不算配置错误但确实是个统计口径陷阱。如果你想让思考时间影响事务统计结果那就明确勾选并在报告里备注“事务时间包含思考时间”如果不想要就保持默认不勾选。最怕的是大家口径不一致开发说事务响应时间太高性能测试这边又说这是合理思考时间来回扯皮。建议在测试方案里就把这个口径写清楚。6.3 嵌套事务导致报告时间重复叠加事务控制器可以嵌套使用比如外层是“完整下单”内层是“支付环节”。这种结构不是不行但要清楚聚合报告里外层事务的时间会包含内层事务的时间因为内层事务是外层事务的子采样器之一。当你看报告时外层的平均响应时间一定大于内层这个大小关系是正常的但如果你把两个事务的时间相加就会重复计算。我的建议是尽量少用嵌套事务一个业务链路只设置一层事务控制器。如果既要看完整链路又要看关键子环节可以复制脚本分别统计而不是在同一份报告里用嵌套结构。否则最终汇报时很容易出现数据对不上的尴尬。6.4 事务控制器里的变量提取失败事务照样显示成功这是坑里最隐蔽的一个。事务控制器本身没有断言它只负责统计时间和汇总成功失败。如果查询接口返回的是200状态码但响应体里是一个业务错误码比如{code:5001,msg:token无效}JMeter默认情况下不会认为这个请求失败因为HTTP状态码是2xx。这样一来你的事务成功率还是100%但实际上业务完全没跑通。所以不要只依赖事务控制器的成功失败状态必须在关键接口上配置响应断言校验业务返回码而不是只看HTTP状态码。我见过不止一个项目因为没做业务断言压测报告全部绿色上线后一查数据全是无效请求。这些坑总结起来其实就是一句话事务控制器只是一个“打包计时器”它不知道对错也不知道业务逻辑所有对业务正确性的判断都得靠你自己在子请求上加断言。把断言加好把统计口径定清楚事务控制器就是你压测脚本里最靠谱的业务链路分析工具。