JMeter-解决上一接口响应时间过长，导致下一接口取不到其提交结果的问题

原创 已于 2022-04-19 10:41:52 修改 · 2k 阅读 · 4 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#jmeter

于 2022-02-28 14:18:52 首次发布
本文探讨了接口A响应过长导致接口B查询等待的问题，通过在接口B中使用While控制器并配合正则表达式提取器，实现在数据未返回时持续查询，有效解决了查询延时问题，提高了系统并发效率。

一、问题描述
场景：接口A提交后，接口B执行查询，去查询A所提交的结果数据
问题：接口A提交后，响应时间过长，导致接口B不能马上查询到数据，从而导致后续接口无法执行

二、解决思路
循环执行接口B，直到接口B查询到数据

三、实现步骤
（1）对接口B添加一个逻辑控制器：While控制器，如下图：
while控制器里的判断条件：${__groovy("${getId}"=="",)}，表示当${getId}这个参数值为空则再次执行while控制器里的请求（即接口B）；
在这里插入图片描述
注：这里有个坑，接口B下添加的获取文件id的后置处理器应选用“正则表达式提取器”，不能选用“JSON提取器”，否则While控制器不生效；具体原因没能探究出来，但实践出来的是这样的结果；

（2）执行结果
在这里插入图片描述
在这里插入图片描述

如何使用jmeter在单个请求中一次推送500条商品数据？
**My Coding Family**
06-21 952
ok，以上就是我这期的Bug修复内容啦，如果还想查找更多解决方案，你可以看看我专门收集Bug及提供解决方案的专栏「Bug调优」，都是实战中碰到的Bug，希望对你有所帮助。到此，咱们下期拜拜。码字不易，如果这篇文章对你有所帮助，帮忙给bugj菌来个，您的支持就是我坚持写作分享知识点传播技术的最大动力。「猿圈奇妙屋」；
JMeter压力测试全攻略：从入门到精通
最新发布
邓邓子的博客
07-04 2052
本文系统讲解JMeter压力测试的完整流程与结果评估方法。开篇介绍压力测试的核心概念及JMeter工具特性，随后从环境搭建入手，详细说明JDK配置、JMeter安装及中文界面设置。主体部分围绕测试流程展开，涵盖测试计划创建、线程组参数调优、HTTP请求配置、断言与监听器添加等实操步骤；结果评估环节深入解析聚合报告指标、结果树分析及性能瓶颈定位方法，并通过电商接口测试案例演示全流程应用。文末总结关键要点，为读者提供从基础操作到分布式压测、性能调优的进阶学习方向，助力掌握JMeter在系统性能评估中的核心应用。
jmeter设置循环后，取不到想要的参数，求大神指点
typrotech的博客
12-14 555
iteamId是取的上个接口的返参，使用循环控制器，线程组设置1，第一次请求没问题，第二次请求，这个iteamId取不到值。后面的线程组都拿不到iteamId。
本地联调和服务器接口响应时间过长引起的超时问题
meimeib的博客
07-16 1790
本地联调接口响应时间过长引起的超时问题 原因 webpack proxy默认连接时间是2000s 解决办法 设置proxy的超时时间 module.exports = { lintOnSave: false, devServer: { port: 8080, // 默认端口号 host: '0.0.0.0', // 任意地址可访问本机 open: true, // 配置自动启动浏览器 proxy: { '/': { target: 'htt
Jmeter对异步接口进行压测，第一个接口返回后，第二个接口取第一个接口的结果重复请求直到正确响应
linss044的博客
04-01 2196
我是小白，我很菜这次压测的接口有个业务：获取局部区域的用户详单，先调用创建任务接口创建任务返回任务ID，后台创建任务后开始计算，再调用获取详情接口发送任务ID请求，若任务未有结果则返回计算中，任务完成计算后，返回详单数据。
JMeter 当前接口请求失败停止请求下一个接口
m0_37587900的博客
03-16 859
第一步：新增if controller，表达式为 ${JMeterThread.last_sample_ok}第二步：将所有接口放在if controller下面，对接口设置断言。
jmeter执行稳定性测试时，因时间过长，导致jtl文件过大
lw的博客
06-20 2066
jmeter稳定性测试解决报告过大问题
接口测试JMeter-1.接口测试初识
07-18 1345
​ 接口主要用于外部系统与系统之间以及内部各个子系统之间的交互点，定义特定的交互点，然后通过这些交互点来，通过一些特殊的规则也就是协议，来进行数据之间的交互。​ 系统组件间接口测试。主要是检测外部系统与系统之间，以及内部各个子系统之间的交互点，检查数据的交换，传递，和控制管理过程，以及系统间的相互逻辑依赖关系，适用于为其他系统提供服务的底层框架系统和中心服务系统，主要测试这些系统对外部系统提供的接口，验证其正确性与稳定性 —百度百科。
第九节 JMeter基础-高级登录【接口关联-鉴权】
weixin_42462845的博客
07-19 880
本文介绍了使用JMeter进行电商功能测试，包括登录、加入购物车等操作的接口关联和参数传递。重点讲解了如何使用JMeter的JSON提取器、HTTP信息头管理器等工具，以及处理token鉴权和JSON格式错误等常见问题。
jmeter请求延迟-Test Action（Flow Control Action）
jinwu18的博客
05-14 3698
在jmeter使用过程中，接口之间相关关联，而有些接口响应时间较长，导致下个接口执行时，可能未能获取到需要的信息。这个时候需要对上个接口做延时处理，就用到Test Action。使用默认选项【Current Thread】及【Pause】，在【Duration】处填写需要延迟的时间即可。 备注： Target：对那个进程做延迟 Action：暂停/停止/进入下个循环 Duration：延迟时间，单位为毫秒，1000毫秒=1秒 ...
jmeter使用正则表达式提取器实现接口关联
03-13
jmeter使用正则表达式提取器实现接口关联
使用JMeter进行压力测试时遇到的上传速度变慢问题
Mezc009的博客
08-03 1041
项目是使用python以及java编程语言进行书写的,使用了docker进行的线上测试发布,又通过Jmeter工具进行的压力测试,测试的时间相对较长.由于测试的服务需要图片文件的上传,因此需要较大的上传带宽,在测试的过程中,猛然发现JMeterd中的汇总报告以及任务管理器中的上传速度骤降,找了很久就是找不到原因,中间还换了JMeter的版本号,还是不行.最后又重新写了一遍.jmx文件,发现速度居然又上来了,网上也没找到相应的答案,暂时理解为JMeter的一个BUG ...
jmeter 上使用json提取器
测试媛
12-10 1048
想让上一个接口的出参作为下一个接口的入参： 使用Jmeter的json提取器或者的出参作为下一个接口的入参： 使用Jmeter的json提取器或者正则表达式可以解决这个问题 json提取器： JSON Path expressions: 返回内容如下： { "status":200, "data":[{"id":101,"name":"张无忌"},{"id":102,"nam...
JMeter定时器设置延迟与同步
weixin_48967543的博客
06-12 1432
JMeter定时器一般用来设置延迟与同步。它的作用域和优先级如下： 定时器的优先级高于Sampler。 在同一作用域（比如控制器下）有多个定时器存在，每个定时器都会执行。 在某一Sampler节点下的定时器，只对这个Sampler有效。 JMeter一共有9种定时器： Constant Timer领券 www.cps3.cn 固定值，多用来模拟思考时间。 Uniform Random Timer 随机时间，分布会更均匀。 Random Delay Maximum：随机延迟时间。 Constant D.
JMeter工具接口性能压力测试分析与优化
qq_53703920的博客
03-03 1290
所做的项目，要求对相关接口做性能压力测试，在这里记录一下分析解决过程。 压力测试过程中，如果因为资源使用瓶颈等问题引发最直接性能问题是业务交易响应时间偏大，TPS逐渐降低等。而问题定位分析通常情况下，最优先排查的是监控服务器资源利用率，例如先用TOP 或者nmon等查看CPU、内存使用情况，然后在排查IO问题，例如网络IO、磁盘IO的问题。 如果是磁盘IO问题，一般问题是SQL语法问题、MYSQL参数配置问题、服务器自身硬件瓶颈导致IOPS吞吐率问题。 　　一、具体测试结果如下： A接口、B接口性能壓力
jmeter 软件性能测试（一）
xuyuan1998的博客
09-03 1148
软件性能测试（初学者）（一） 随着现在的互联网的高速发展，性能测试都是一个高热点的话题，系统上线后，性能的好坏直接就影响了用户使用系统的体验，相信没有一个用户能接受一个网站打开时间超过10S，如果是我超过5S我都等不了，呵呵。。。因此性能测试是任何一个系统、软件在正式发布前需要重点关注的一个点。 别的不说，还是先开始了解下关于性能测试的基础知识。 常见的性能测试指标 判断一个系统的好坏，在性能测试中会使用一些指标来进行分析和描述，以下是一些常用的指标因素： 事务处理的响应时间 这里的响应时间指的是 某个操
Jmeter 自动化性能测试常见问题汇总
主要分享测试的学习资源，帮助快速了解测试行业，帮助想转行、进阶、小白成长为高级测试工程师。
06-02 3543
一、request 请求超时设置 timeout 超时时间是可以手动设置的，新建一个 http 请求，在“高级”设置中找到“超时”设置，设置连接、响应时间为2000ms。
记一次Jmeter高并发，问题定位、系统优化过程
wusefengye的博客
07-11 1030
先说结论 现象：JMeter 通过模拟大量的源IP（1300个IP）发送到Tomcat服务器端，出现不少接口响应超时 connect timeout。 原因：Linux系统对于Arp表的数目有上限：1024，大量并发请求产生时，无法生成ARP表象，导致超时 修改点： 1、vim /etc/sysctl.conf 添加 net.ipv4.neigh.default.gc_thresh1 = 2048 net.ipv4.neigh.default.gc_thresh2 = 4096 ne...
Jmeter基础---while控制器举例说明
软件测试技术资源分享官
10-26 1638
首先创建一个While Controller (While 循环控制器) ​​
jmeter响应时间与吞吐量不匹配
02-27
<think>好的，我现在需要帮助用户解决关于JMeter中响应时间与吞吐量不匹配的问题。首先，我得理解这两个概念以及它们之间的关系。响应时间是指从发送请求到接收到响应所用的时间，而吞吐量是单位时间内处理的请求数量。通常，吞吐量越高，响应时间可能也会增加，但有时候会出现两者不匹配的情况，比如吞吐量低而响应时间却很长，或者相反。 接下来，我需要考虑可能的原因。首先，服务器性能可能是一个因素。如果服务器资源（如CPU、内存）不足，即使响应时间很长，吞吐量也可能上不去，因为服务器处理能力受限。这时候应该检查服务器的资源使用情况，看看是否有瓶颈。 然后是网络延迟。如果网络延迟高，响应时间会增加，但实际的服务器处理时间可能很短，这样吞吐量可能不会显著下降。用户可能在测试时遇到了网络问题，导致响应时间虚高，但吞吐量并没有按预期变化。 线程组配置也是一个关键点。比如，线程数设置不合理。如果线程数太少，无法产生足够的负载，吞吐量自然低，而响应时间可能因为请求少而显得较低。相反，如果线程数过多，服务器可能过载，导致响应时间急剧上升，而吞吐量反而下降。需要建议用户检查线程组的配置，比如逐步增加线程数观察变化。 定时器的使用也可能影响结果。比如，在测试中使用了固定定时器或随机定时器，导致请求之间有间隔，这样吞吐量会被限制，而响应时间可能因为间隔的存在而看起来较低。需要提醒用户检查是否有不必要的定时器，或者间隔时间设置是否合理。 响应时间的数据处理方式也可能导致误解。例如，用户可能只关注了平均响应时间，而忽略了中位数或百分位数。如果有部分请求响应时间特别长，平均时间会被拉高，但吞吐量可能还是正常的。建议用户查看不同百分位的响应时间，比如90%或95%。 测试持续时间不足也可能导致数据不准确。如果测试时间太短，可能无法达到稳定的吞吐量，响应时间数据也不可靠。需要建议延长测试时间，确保系统进入稳定状态后再收集数据。 其他因素包括测试环境的问题，比如被测系统本身的性能瓶颈、JMeter客户端的资源限制（如本机CPU、内存不足导致无法发送足够请求）、或者测试脚本中存在逻辑错误（如参数化或断言处理不当）。 最后，需要给出排查步骤：检查服务器资源、网络状况；调整线程组配置；去除不必要的定时器；分析响应时间分布；确保测试时长足够；监控JMeter客户端资源使用情况。通过这些步骤，用户可以逐步定位问题原因，进而优化测试配置。</think>在JMeter性能测试中，响应时间（Response Time）与吞吐量（Throughput）理论上应呈反比关系，但实际测试中可能出现不匹配现象。以下是常见原因及排查思路： --- ### 一、核心概念关系 - **响应时间**：单个请求从发送到接收响应的时间（单位：ms） - **吞吐量**：单位时间（秒）内处理的请求量（单位：请求数/秒） - **理想关系**：吞吐量↑ → 响应时间↑（因资源竞争加剧），但当系统过载时会出现吞吐量↓ + 响应时间↑ --- ### 二、常见不匹配场景分析 #### 1. 吞吐量低但响应时间高 **现象**：`Throughput=5/sec`，`Avg Response Time=8000ms` **可能原因**： - **服务器资源瓶颈**（CPU/内存/磁盘过载） - **网络延迟**（如跨地域请求、带宽不足） - **外部依赖阻塞**（数据库锁、第三方API限速） - **JMeter自身限制**（客户端资源耗尽） #### 2. 吞吐量高但响应时间低 **现象**：`Throughput=200/sec`，`Avg Response Time=50ms` **可能原因**： - **缓存命中率高**（请求重复性高） - **服务器优化过度**（如批量处理未生效） - **测试脚本错误**（未执行完整业务流） --- ### 三、排查步骤（附解决方向） 1. **检查服务器资源** ```bash # Linux服务器监控命令 top # CPU/MEM iostat -x # 磁盘IO netstat -nat | awk '{print $6}' | sort | uniq -c # 连接状态 ``` - **发现CPU使用率>80%** → 优化代码或扩容 2. **验证网络延迟** ```bash traceroute 目标服务器IP ping -c 100 目标服务器IP # 观察丢包率 ``` - **跨机房延迟>100ms** → 调整网络架构 3. **分析JMeter配置** - **不合理配置**： ```xml <!-- 错误示例：线程组瞬间启动过多线程 --> <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="错误配置" enabled="true"> <elementProp name="ThreadGroup.main_controller" elementType="LoopController"> <boolProp name="LoopController.continue_forever">false</boolProp> <stringProp name="LoopController.loops">1</stringProp> </elementProp> <stringProp name="ThreadGroup.num_threads">500</stringProp> <!-- 瞬间启动500线程 --> <stringProp name="ThreadGroup.ramp_time">0</stringProp> <!-- 无梯度加压 --> </ThreadGroup> ``` - **正确做法**：使用`Stepping Thread Group`插件实现梯度加压 4. **检查定时器干扰** - 删除不必要的`Constant Timer`，或调整`Random Timer`的时间范围 - 使用`Throughput Shaping Timer`精确控制吞吐量 5. **分析响应时间分布** ```csv # 在聚合报告中关注： 90% Line Response Time = 1200ms # 90%请求<=1200ms 95% Line Response Time = 3500ms # 长尾请求影响平均值 ``` - **长尾请求过多** → 优化慢查询/接口 --- ### 四、典型解决方案 | 场景 | 优化措施 | |------|----------| | 高响应时间+低吞吐量 | 扩容服务器集群，优化SQL查询，增加CDN | | 低响应时间+异常高吞吐量 | 检查脚本是否跳过了业务逻辑（如未提交订单） | | 吞吐量波动剧烈 | 使用`Constant Throughput Timer`稳定压力 | --- ### 五、验证方法 1. 使用`Server Agent`监控被测服务器资源 2. 在JMeter中添加`Active Threads Over Time`监听器，观察并发与吞吐量的对应关系 3. 通过`JConsole`或`VisualVM`分析应用线程状态 通过以上方法，可系统性定位响应时间与吞吐量不匹配的根本原因，建议每次只调整一个变量进行对比测试。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值