2种方式实现JMeter多接口指定TPS同时并发

该文章详细介绍了如何使用JMeter工具进行多线程组的并发测试,包括设置线程组的并发数、循环次数和调度器,添加HTTP信息头管理器来处理请求头,使用ConstantThroughputTimer设定目标TPS,创建HTTP请求模拟接口调用,并添加聚合报告来分析测试结果。

多线程组指定TPS同时并发

示例:接口1、接口2、接口3……

新建线程组

1、右键测试计划,依次选择 添加-Threads-线程组:

 

2、点击线程组,输入并发数;

3、勾选循环次数:永远;

4、勾选调度器:输入执行时间。

 

新建HTTP信息头管理器

右键线程组,依次选择添加-配置元件-HTTP信息头管理器:

 点击添加按钮,输入信息头请求参数名称和值,与请求格式(Content-Type)。

 

注:

若所有接口请求头相同,可直接在测试计划节点下新建一个HTTP信息头管理器;

若不相同,则需在对应线程组下各新建一个HTTP信息头管理器。

新建吞吐量计时器

右键线程组,依次选择添加-定时器- Constant Throughput Timer。

 

Target Throughput输入目标TPS(转换成毫秒输入)。

Calculate Throughput based on:选择this thread only。

 

新建HTTP请求(接口1)

1、右键线程组,依次选择 添加-Sampler-Http请求。

 

2、选择HTTP请求方法

3、填写HTTP请求地址;

4、填写请求参数。

接口2、3新建步骤同上(重复1、2、3、4步),可直接右键线程组复制,右键测试计划粘贴。

添加聚合报告

右键测试计划,依次选择 添加-监听器-聚合报告。

 点击执行按钮,执行完成后,查看聚合报告。

 聚合报告各字段说明

  • 1、Label - 请求对应的name属性值。
  • 2、Samples - 具有相同标号的样本数,总的发出请求数。
  • 3、Average - 请求的平均响应时间。
  • 4、Median - 50%的样本都没有超过这个时间。这个值是指把所有数据按由小到大将其排列,就是排列在第50%的值。
  • 5、90% Line - 90%的样本都没有超过这个时间。这个值是指把所有数据按由小到大将其排列,就是排列在第90%的值。
  • 6、95% Line - 95%的样本都没有超过这个时间。这个值是指把所有数据按由小到大将其排列,就是排列在第95%的值。
  • 7、99% Line - 99%的样本都没有超过这个时间。这个值是指把所有数据按由小到大将其排列,就是排列在第99%的值。
  • 8、Min - 最小响应时间。
  • 9、Max - 最大响应时间。
  • 10、Error % - 本次测试中,有错误请求的百分比。
  • 11、Throughput - 吞吐量是以每秒/分钟/小时的请求量来度量的。这里表示每秒完成的请求数。
  • 12、Received KB/sec - 收到的千字节每秒的吞吐量测试。
  • 13、Sent KB/sec - 发送的千字节每秒的吞吐量测试。

单线程组指定TPS同时并发

1、线程组下创建Constant Throughput Timer,设定TPS。

2、线程组下创建吞吐量控制器,设定第一步TPS百分比。

3、吞吐量控制器下创建HTTP请求,每个吞吐量控制器的百分比之和=100%。


资源分享

下方这份完整的软件测试视频学习教程已经上传优快云官方认证的二维码,朋友们如果需要可以自行免费领取 【保证100%免费】

 这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!

软件测试面试文档

我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。

 

<think> 我们正在讨论如何使用JMeter确定一个接口的最大并发数。最大并发数通常指的是系统在保证可接受响应时间的前提下,能够同时处理的最大请求数量。根据引用[1]和引用[2],我们可以结合阶梯式压力测试和吞吐量控制来实现。 方法概述: 1. **阶梯式压力测试(Stepping Thread Group)**:逐步增加并发用户数,观察系统性能指标(如响应时间、错误率)的变化,直到系统性能出现拐点(如响应时间急剧上升或错误率增加),此时拐点前的并发数即为最大并发数。 2. **吞吐量控制(Constant Throughput Timer)**:通过控制吞吐量来模拟不同的负载,但在这个场景中,我们更关注的是并发用户数,所以阶梯式压力测试是主要方法。 具体步骤: ### 1. 配置线程组 使用`jp@gc - Stepping Thread Group`(需要安装插件)来逐步增加并发用户数。根据引用[1]中的示例,我们可以设置如下: - 起始并发数:10 - 每1秒增加1个并发用户数,直到达到20 - 在20并发时持续运行60秒 - 然后每1秒减少5个并发用户数,直到0 但是,为了找到最大并发数,我们需要逐渐增加并发直到系统出现瓶颈。因此,我们可以修改为: - 起始并发数:例如10 - 每次递增的并发数(步长)和等待时间:例如每30秒增加10个并发用户(这样系统有足够时间稳定) - 直到某个并发数下系统出现性能下降(如错误率增加或响应时间超过阈值) ### 2. 添加监听器 添加以下监听器来监控性能指标: - 聚合报告(Aggregate Report) - 响应时间图(Response Time Graph) - 活动线程数图(Active Threads Over Time) - 每秒事务数(Transactions per Second) ### 3. 确定性能拐点 在阶梯式增加并发用户数的过程中,观察: - 响应时间:是否在某个并发数后突然上升 - 错误率:是否在某个并发数后开始出现错误(如HTTP 500或超时) - 吞吐量:是否在某个并发数后不再增长甚至下降 当这些指标出现明显恶化时,前一个并发数级别即为该接口的最大并发数。 ### 4. 使用公式验证 在性能测试中,我们可以利用以下公式来估算最大并发数: $$最大并发数 \approx \frac{最大吞吐量(TPS)}{单个请求平均响应时间(秒)}$$ 但是,实际最大并发数还会受到系统资源(如线程池、连接池)的限制,所以需要通过测试验证。 ### 5. 使用常数吞吐量定时器(可选) 引用[2]中提到,可以使用`Constant Throughput Timer`来控制吞吐量。如果我们已经知道系统期望的吞吐量,可以设置目标吞吐量,然后观察在该吞吐量下需要多少并发用户,从而间接确定最大并发数。但注意,这种方法更适合稳定性测试,而不是找最大并发数。 示例配置`Constant Throughput Timer`: - Target throughput (in samples per minute): 例如6000(即100 TPS) - Calculate Throughput based on: all active threads ### 6. 注意事项 - **思考时间(Think Time)**:如果模拟用户操作,需要添加合理的思考时间,否则可能压垮系统。 - **断言**:添加断言验证接口返回的正确性。 - **资源监控**:同时监控服务器资源(CPU、内存、网络等),以确定瓶颈来源。 根据引用[1]的阶梯式线程组配置,我们可以设计一个寻找最大并发数的测试计划: 步骤示例(使用Stepping Thread Group): 1. 起始并发数:10 2. 每30秒增加10个线程(即每30秒增加10个并发用户) 3. 直到达到某个上限(如100),或者直到系统出现性能问题 通过上述步骤,我们可以绘制出并发用户数与响应时间/错误率的关系图,从而确定最大并发数。 相关问题: 1. 如何分析JMeter测试结果以确定系统瓶颈? 2. 在分布式测试环境下如何配置JMeter? 3. 如何模拟真实用户行为进行压力测试? 4. 如何通过JMeter进行长时间稳定性测试? 以上方法结合了阶梯式压力测试和关键性能指标分析,能够有效确定接口的最大并发用户数。 </think> 使用JMeter确定接口最大并发数需通过**阶梯加压测试**实现,核心是通过逐步增加并发用户数,监控系统性能拐点。以下是具体方法及操作步骤: --- ### 一、测试原理 1. **性能拐点识别** 当并发用户数$N$持续增加时,系统会经历三个阶段: - **性能稳定期**:响应时间平稳,错误率≈0% - **性能拐点**:响应时间陡增,错误率上升(如>1%) - **性能崩溃期**:大量超时/错误 **最大并发数** = 拐点前的并发用户数$N_{max}$ 2. **关键公式** $$吞吐量(TPS) = \frac{成功请求数}{测试时间}$$ 当$TPS$停止增长或下降时,即为拐点[^1]。 --- ### 二、操作步骤(使用`Stepping Thread Group`插件) #### 1. **配置阶梯加压线程组** ```mermaid graph LR A[起始10并发] --> B[每1秒+1并发] B --> C{并发数≥20?} C --否--> B C --是--> D[维持60秒] D --> E[每1秒-5并发] E --> F{并发数=0?} F --否--> E F --是--> G[结束] ``` - **参数设置**(参考引用[1]): - 起始并发:10用户 - 增量:每1秒增加1用户 - 目标上限:20用户(持续60秒) - 减压:每1秒减少5用户至0 > **注**:目标上限需根据预估调整(如从50开始测试)。 #### 2. **添加监听器监控指标 | 监听器类型 | 监控指标 | 拐点判断依据 | |---------------------|----------------------------|--------------------------| | 响应时间图 | 平均响应时间(ms) | 突增>50%基线 | | 聚合报告 | 错误率(%) | >1%即达拐点[^2] | | Transactions per Second | TPS(事务/秒) | TPS曲线走平或下降 | | 服务器资源监控 | CPU/内存使用率 | CPU>85%或内存溢出 | #### 3. **设置断言与超时** - 添加**响应断言**验证HTTP状态码(如非200即失败) - 设置**请求超时**:通常≤3秒(超时记为失败) #### 4. **分析测试结果 - **拐点判定示例**: - 并发用户数15时:平均响应时间=150ms,错误率=0% - 并发用户数16时:平均响应时间=420ms,错误率=3% → **最大并发数=15** --- ### 三、高级优化技巧 1. **精准定位拐点** - 在疑似拐点区间(如15-20并发)缩小步长:每30秒+1用户 - 使用**吞吐量控制器**(引用[2])精细化负载分配 2. **排除干扰因素** - 启用**思考时间**:模拟真实用户操作间隔 - 关闭JMeter本地资源监控(避免自身性能影响结果) 3. **分布式测试** 单机JMeter最多支持300-500并发,更高并发需使用**多机负载集群**。 --- ### 四、典型问题排查 | 现象 | 可能原因 | 解决方案 | |---------------------|-------------------------|----------------------| | TPS未达预期 | 数据库连接池不足 | 扩大连接池大小 | | 高并发下响应超时 | 服务端线程阻塞 | 优化线程池策略 | | 错误率突增 | 接口未做限流熔断 | 添加熔断机制 | > **关键提示**:最大并发数会随系统优化动态变化,需定期复测[^1][^2]。 --- **相关问题** 1. 如何通过TPS曲线判断系统瓶颈类型? 2. 分布式测试中如何同步多台JMeter机器的测试数据? 3. 除了并发用户数,还有哪些指标可以评估接口容量? 4. 如何区分性能拐点是由被测接口还是依赖服务引起的? [^1]: 阶梯加压法可精准定位性能拐点 [^2]: TPS和错误率是核心判据
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值