Jmeter(五)性能压测

一、压力测试场景设置--windows环境

  压力测试:一般压测时间10-15min,N个并发用户一直在请求。监控服务的cpu、内存等;

  稳定性测试:一般压测一周,2天,1天等,看系统会不会崩掉,会不会内存泄露等。

一般我们在做压力测试的时候,分单场景和混合场景,单场景也就是咱们压测单个接口的时候,多场景也就是有业务流程的情况下,比如说一个购物流程,那么这样的场景就是混合场景,就是有多个接口一起来做操作。

     1、单场景,一个请求就可以了

     2、混合场景,多个请求

     3、压测时间,一般场景都是运行10-15分钟,如果是做疲劳测试的话,可以压一天或者一周,根据具体的情况来定。

压测配置如图:

添加聚合报告,添加步骤如下:

备注:

在做压测的时候,数据量少和数据量大的情况下,测试的结果是不一样的,所以,我们在设计场景的时候是要考虑到这种情况的,要测试数据库中数据量大和数据量小的情况,如果是要测试数据量大的情况下,就要造数据了,造数据可以使用jmeter,操作数据库来造数据,也可以使用python连接数据库,批量的造数据。

二、压力测试结果查看

查看结果关注的几个指标:

1、tps是每秒钟处理的请求数,也就是指服务器的处理能力,tps越高说明服务器处理能力越好

2、响应时间,也就是每个请求的处理时间

3、并发用户数 也就是多少并发

线程组->添加->聚合报告:
samples:发出了多少请求
Average:平均响应时间,单位ms
throughput:代表tps,每秒能处理多少请求
error:若是现金支付,则应该是100%。

三、Linux下运行jmeter压力测试

我们在做测试的时候,有时候要运行很久,公司用的测试服务器一般都是linux,就可以运行在linux下面,linux下面不能像windows一样有图形化界面,那怎么运行脚本呢,就先在windows上把脚本做好,然后在linux下运行即可,linux下运行jmeter是在jmeter的bin目录下的jmeter.sh这个shell脚本。 sh jmeter.sh -n –t a.jmx -l res.jtl -n代表以没有图形化界面启动,-t代表后面是测试脚本,a.jmx也就是我们做好的jmeter脚本,-l代表测试结果 res.jtl就是测试结果文件,查看结果的话,在查看结果树视图中导入这个res.jtl就可以查看到测试结果了

 

四、jmeter分布式压测

jmeter分布式压测(多台电脑一起压测)
(1)有多台电脑,每台电脑都装好jmeter,而且这几台电脑都互相能ping通;一台master控制多台。
(2)在我的电脑的jmeter的配置文件里面添加其他人电脑的ip。通过jmeter配置文件jmeter.properties,添加:remote_hosts=localhost:1099,{要控制的ip}:1099。
(3)在其他人电脑上要启动jmeter-server.bat
ps:如果有参数化文件,那么也要在其他人的电脑的同样位置放一份。
以上操作之后要重启jmeter。
全部电脑一起运行方法:点击菜单栏的“运行->远程全部启动”。或者点击菜单栏中带有两个绿色箭头的按钮。

五、非图形化界面操作

非图形化界面下运行(例如:linux下运行)
(1)没有图形化界面运行。
(2)先把jmeter的bin目录加入到环境变量里面。运行cmd,输入jmeter -v ,进入没有图形化界面,类似linux。
然后执行:
jmeter -n -t HTTP请求.jmx -l D:/path/res.jtl
-n 代表在没有图形话界面下运行
-t 制定一个测试脚本
-l 指定结果文件,这个文件要以.jtl结尾。不写路径就是在当前路径。若写绝对路径,则指定存放路径。

原文地址:https://www.cnblogs.com/xm-sunnylin/p/9511708.html

时间: 2024-11-08 05:56:26

Jmeter(五)性能压测的相关文章

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

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

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

前段时间有描述过性能的测试类型 配置负载 Big Bang: 负载同时产生 Ramp up: 开始时候产生一定负载,然后每隔一段时间增加一些负载直到达到目标负载,这是典型模式 Ramp-up (with step): 分段产生负载.比如总共需要1000用户的负载,但是我们需要观察系统在250, 500, 700负载下的表现,到达这些负载后需要跑一段时间再增加新负载 Ramp up (with step), ramp down (with step): 跟上面类似,只是最后负载回归到0 Delay

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

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

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

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

后端服务性能压测实践

转自: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

Mongodb性能压测

一.背景 这几天对所有的基础组件做一个摸底的基准压力测试,目前我们所有的开源基础组件都没有做过性能测试,经常有开发人员问,我们的RDS.MongoDB集群能抗多大量呀,这个时候我是没办法回复的,因为我自己也不知道,虽然一个数据库集群能抗多大量,在软件.硬件配置固定的情况下,和业务场景有很大的关系,如果数据量小,查询SQL简单那吞吐量自然很高,如果数据量特别大并且都是复杂SQL,那吞吐量自然上不去:但是既然人家问了,肯定是希望有一个答案,如果你说不知道,那会给人一种不靠谱的感觉,所以做一次基准压力