Jmeter之性能压测Stepping Thread Group 逐步增加并发数 阶梯式加压并发 (十五)

前段时间有描述过性能的测试类型

  • 配置负载
  1. Big Bang: 负载同时产生
  2. Ramp up: 开始时候产生一定负载,然后每隔一段时间增加一些负载直到达到目标负载,这是典型模式
  3. Ramp-up (with step): 分段产生负载。比如总共需要1000用户的负载,但是我们需要观察系统在250, 500, 700负载下的表现,到达这些负载后需要跑一段时间再增加新负载
  4. Ramp up (with step), ramp down (with step): 跟上面类似,只是最后负载回归到0
  5. Delayed start: 延迟开始
  • 测试流程
  1. 对每个用例进行容量测试:负载策略一般是ramp-up或者ramp-up with step
  2. 对出现性能问题的用例进行隔离测试
  3. 对用例组进行容量测试
  4. 对用例组进行隔离测试:负载策略一般是ramp-up或者ramp-up with step
  5. 对用例组进行压力测试
  6. 对用例组进行稳定性测试

对于配置负载的加压方式的设置 需要安装一个插件 才能使用 Stepping Thread Group

下载链接:https://jmeter-plugins.org/downloads/old/

下载解压后,将JMeterPlugins-Standard.jar包放在jmeter安装目录的jmeter-3.0\lib\ext路径下,重新启动jemter即可。 这个在之前的文章也过安装方式。

功能参数设置This group will start 100 threads:设置线程组启动的线程总数为100个;

First,wait for N seconds:启动第一个线程之前,需要等待N秒;

Then start N threads:设置最开始时启动N个线程;

Next,add 10 threads every 30 seconds,using ramp-up 5 seconds:每隔10秒,在30秒内启动5个线程;

Then hold load for 60 seconds:启动的线程总数达到最大值之后,再持续运行60秒;

Finally,stop 5 threads every 1 seconds:每隔5秒,停止1个线程;

原文地址:https://www.cnblogs.com/Lam7/p/8340822.html

时间: 2024-10-08 23:54:53

Jmeter之性能压测Stepping Thread Group 逐步增加并发数 阶梯式加压并发 (十五)的相关文章

Jmeter服务器性能压测-用户登录实例CSV方式

为什么用CSV方式压测,因为用jdbc链接数据库,我发现数据库数据量量大的情况下,Jmeter会内存溢出 第一步:数据准备,根据登录接口需要的参数准备测试数据 例子中,测试的登录接口需要4个参数化数据 Step1:数据库直接准备够需要用到的数据,插入还是update随便喽,sql语句可以参考我的分类"sql语句" 比如我用的sqlyog,准备好数据后,导出数据 根据我图片标注,按照需要进行勾选 导出为xls文件,打开后,另存为csv文件 第二步:Jmeter脚本(已添加用户定义的变量)

接口测试及服务器性能压测

目前移动端app大都还是采用的http或者https协议写的restful接口,一般的辅助类http劫持(fiddler,charles)和模拟发送(postman)工具都可以满足单次单个接口的测试需求,但这种依附工具的测试很难满足多接口调用逻辑验证问题,也不太灵活,没办法做到数据化,还有就是对于接口压测和服务器性能压力测试无法满足,又得借助于其他压测工具(Jmeter loadrunner等),设计一套基于http和https灵活定制的接口测试框架还是很有必要的. 一般app接口调用都要都要传

后端服务性能压测实践

转自:https://mp.weixin.qq.com/s/XW9geHZ9odHdI7srDiKBIg 目录 背景 环境检测 压力机及压力工具检测 Linux openfiles limit 设置 排查周边依赖 空接口压测检测 聚合报告中 throughput 计算 压测及性能排查方法 关注各纬度 log Linux 常规命令 性能排查两种方式(从上往下.从下往上) 总结 背景 最近大半年内有过两次负责性能压测的一些工作.一件事情做了一次可能还无法总结出一些东西,两次过后还是能发现一些共性问题

(转)后端服务性能压测实践

作者:王清培(Plen wang) 传送门:https://www.cnblogs.com/wangiqngpei557/p/7953453.html ---------------------------------------------------------------------分割线------------------------------------------------------ 入职新公司,没人理我,负责的需求开发一直很忙,要么环境有问题,要么Bug卡住我找开发,回了一句

感受真实性能压测的“洪荒之力” 压测宝有奖体验中

作为测试,你有没有遇到这样的问题:1.熬了多少个日夜的系统终于快上线了,不知道上线后系统负载能力怎样?2.促销季到了,应用性能如何?到底能不能支持500w并发用户?3.怎么做压测才能更接近线上真实环境? 系统负载有多强,压测一下就知道.云智慧压测宝3步6分钟 开启真实用户的性能压测 8月16至9月2日申请试用压测宝,感受真实压测的洪荒之力,还有机会获得优酷视频会员卡,速速来领- 参与活动赢优酷会员卡 1.从这里申请试用压测宝:[url=http://yacebao.com/landingPage

swingbench-免费的oracle性能压测工具

SwingBench介绍: SwingBench由负载生成器,协调器和集群概述组成.该软件使得能够生成负载并且将图表的事务/响应时间映射. SwingBench可用于演示和测试诸如实际应用集群,在线表重建,备用数据库,在线备份和恢复等技术 SwingBench附带的代码包括6个基准,OrderEntry,SalesHistory,TPC-DS Like,JSON,CallingCircle和StressTest .. OrderEntry基于Oracle11g / Oracle12c附带的"oe

性能压测诡异的Requests/second 响应刺尖问题

最近一段时间都在忙着转java项目最后的冲刺,前期的coding翻代码.debug.fixbug都逐渐收尾,进入上线前的性能压测. 虽然不是大促前的性能压测要求,但是为了安全起见,需要摸个底心里有个数. 毕竟这次转java的服务都是集团核心公共服务(主要是订单域服务).(等我们顺利上线了,我再来好好总结下其中的坎坷和壮举.) 废话不多说了,直接进入主题. 由于这次压测主要重点是关注正向的两个核心订单服务,下单服务.查单服务.查单服务初步压测下来问题不大,主要是db的索引和cache的问题. 下单

Ultimate thread group线程组和Stepping thread group线程组测试场景

Ultimate thread group线程组 当测试需求是要求进行波浪型的压力测试场景时,使用该线程组,例如:测试场景总共有10个线程,然后分为三个波段进行测试,每个波段负载策略设置为一样,如图: 注意,这里是设置了三个线程计划,每个线程计划并发10个,是在时间轴上按顺序执行的,因此场景最高并发用户是10个,而非30个并发用户. 2.当测试需求是要求进行阶梯型的压力测试场景时,使用该线程组.例如:测试场景总共有30个线程,然后分为三次逐渐增加负载,每次增加负载10个线程,如图: 注意,这里是

Jmeter(五)性能压测

一.压力测试场景设置--windows环境 压力测试:一般压测时间10-15min,N个并发用户一直在请求.监控服务的cpu.内存等: 稳定性测试:一般压测一周,2天,1天等,看系统会不会崩掉,会不会内存泄露等. 一般我们在做压力测试的时候,分单场景和混合场景,单场景也就是咱们压测单个接口的时候,多场景也就是有业务流程的情况下,比如说一个购物流程,那么这样的场景就是混合场景,就是有多个接口一起来做操作. 1.单场景,一个请求就可以了  2.混合场景,多个请求 3.压测时间,一般场景都是运行10-