全网最牛,JMeter性能测试步骤与结果分析(压力 / 负载测试)详全,精品太干了
目录:导读
一、前言
负载:模拟业务操作对服务器造成压力的过程,比如模拟100个用户进行发帖
在一定软硬件环境下,通过不断加大负载(不同虚拟用户量)来确定在满足性能指标情况下能够承受的最大用户数
简单说,可以帮我们对系统进行定容 定量,找出系统性能的拐点,给予生产环境规划建议。这里的性能指标包括TPS (每秒事务数)、RT(事务平均响应时间)、CPU Using(CPU利用率)、Mem Using(内存使用情况)等软硬件指标
从操作层面来说,负载测试也是一种性 能测试手段,比如下面的配置测试就需要变换不同的负载来进行测试
压力、强度测试:
在一定软硬件环境下,通过高负载的手段来使服务器资源(强调服务器资源, 硬件资源)处于极限状态,测试系统在极限状态下长时间运行是否稳定,确定是 否稳定的指标包括TPS、RT、CPU Using、Mem Using等
二、负载、压力、可靠性(非常重要)
场景类型 | 用户数量(线程数) | 思考时间(固定定时器或高斯随机定时器) | 集合点(同步定时器) | 场景加压(加压时间) | 运行时间(循环次数或配置调度器) | 判定场景成功/失败条件 |
---|---|---|---|---|---|---|
压力(狭义并发) | 50,60, 70, 80… | 禁用 | 开启 | 一次完成 | 一次 | 服务是否崩溃 |
负载 | 50 | 开启高斯随机定时器 | 关闭 | 2-5分钟内完成 | 20分钟–2小时 启用调度器 | 1.事务通过率 2.事务时间 |
可靠 | 10 | 开启高斯随机定时器 | 关闭 | 2-6分钟内完成 启用调度器 | 24小时 36小时 72小时 | 1.内存泄漏(30分钟记录一次内存) 2.服务器是否崩溃 |
三、压力测试实战
线程组设置,这里的线程数与同步定时器的用户数量一样
2、添加HTTP cookie管理器
3、默认请求值
4、添加一个事务控制器,可以当作一个业务
5、在事务控制器下添加,同步定时器
设置用户数量,这里与线程组的线程数一样,超时时间可设置
6、添加脚本(http请求)
7、添加查看结果树
8、添加jp@gc - PerfMon Metrics Collector进行监控CPU、Memory、Disks I/O、Network I/O等。添加处:添加->监听器
9、在最后添加一个聚合报告,添加处:添加->监听器
四、负载测试实战
线程组的设置50个用户(持续时间:按秒计算,这里300=60*5,意思就是运行时长为5分钟)
2、添加HTTP cookie管理器
3、默认请求值
4、添加一个事务控制器,可以当作一个业务
5、在事务控制器下添加,高斯随机定时器
总的延时 = 固定延迟时间 + 高斯随机生成的偏差值(说明:单位都是毫秒,固定延迟300ms,偏差100ms,意思是时间延迟300-400ms之间)
6、添加脚本(http请求)
7、添加jp@gc - PerfMon Metrics Collector进行监控CPU、Memory、Disks I/O、Network I/O等。添加处:添加->监听器
8、在最后添加一个聚合报告,添加处:添加->监听器
五、资源监控
聚合报告、jmeter监控服务器资源
1、Windows自带的资源监工具
5个主要指标:
1.CPU使用率
2.队列长度
3.可用内度
4.硬盘读写时间
5.网络带宽
2、Jmeter里面的第三方监理插件
Perfmon插件
3、Linux资源监控
CPU:top (在命令行输入)
或
more /proc/cpuinfo
内存:
free -m
vmstat 刷新频率
例如:
vmstat 15
(说明:15秒刷新频率)
硬盘大小:
df -mfdisk -l
注意:
1.Error错误率
2.看CPU、内存
3.看聚合报告里面的请求时间
来源地址:https://blog.csdn.net/m0_70102063/article/details/124635486
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341