项目实操四-性能测试过程实时监控分析

本文详细介绍了如何使用JMeter进行性能测试,包括CSV文件驱动、定时器的使用、全局变量传递、JMeter结果查看方式,以及如何利用InfluxDB和Grafana构建实时监控大屏。此外,还讲解了不同类型的性能测试,如基准测试、负载测试和压力测试,以及业务流程性能测试中的 token 处理策略。
摘要由CSDN通过智能技术生成

在这里插入图片描述


一、JMeter性能测试技巧

1、CSV文件驱动

jmeter读取csv文件数据,一行一行的循环读取
单线程、多线程都是一致的
当读取最后一条后,会从头开始继续读取

在这里插入图片描述

2、定时器

a、泊松随机定时器

在这里插入图片描述

在这里插入图片描述

b、固定定时器

通过Thread Delay设定每个线程请求之前的等待时间(单位为毫秒)。注意:固定定时器的延时不会计入当前sampler的响应时间里,但是会计入事务控制器的时间。 对于事务控制器来说,定时器相当于loadrunner中的think time(思考时间:实际操作中,模拟真实用户在操作过程中的等待时间)

通常所说的响应时间,大部分情况下是针对某一个具体的sampler (http请求),而不是针对一组sampler组合的事务。
在这里插入图片描述

c、高斯随机定时器

如果需要每个线程的延迟时间是符合标准正态分布的随机时间停顿,那么使用这个定时器,总延迟=高斯分布值(平均Q.O和标准偏差1.0)*指定的偏差值+固定延迟偏移

(Math.abs((this.random.nextGaussian()*偏差值)+固定延迟偏移))
在这里插入图片描述

d、均衡随机定时器

在这里插入图片描述

e、同步定时器

作用:阻塞线程,直到指定的线程数量到达后,再一起释放,可以瞬间产生很大的压力
在这里插入图片描述

f、固定吞吐量定时器

在这里插入图片描述

g、精准吞吐量定时器

在这里插入图片描述

3、全局变量 - 跨线程数据传递

在这里插入图片描述

用到了Jmeter元件:
计数器:记录当前执行的是第几次,并通过 number 变量保存
JSON提取器:提取登录接口响应体中的token
BeanShell断言:将token设置为全局变量,可以跨线程组使用
HTTP Cookie管理器:提取上面保存的全局变量

4、Debug调试器

查看Jmeter变量以及属性
在这里插入图片描述

5、JMeter执行机端口被占用

在这里插入图片描述

二、JMeter性能测试结果查看三大方式

1、GUI界面报告+插件

缺点:界面模式运行,会额外占用(脚本执行机器)更多的资源

既要模拟对服务器发起请求,还要汇总页面、图片、图标、统计数据。CPU是有限的
jmeter作为施压机 - 核心工作 - 模拟并发
实时做统计,导致并发效果不能匹配性能场景

a、聚合报告

在这里插入图片描述
90%百分位:表示1000个请求有900个请求的响应时间是小于等于36毫秒
95%百分位:表示1000个请求有950个请求的响应时间是小于等于60毫秒返回
99%百分位:表示1000个请求有990个请求的响应时间小于等于135毫秒返回,有10个请求的响应时间大于135毫秒

90%百分位、95%百分位、99%百分位:各个响应时间段的占比

聚合报告相比较汇总报告,多了三个响应时间分布信息
中位数:表示有1000个请求,其中有500个请求小于等于27毫秒,相当于分界线。

b、汇总报告

具体各个字段的说明在上一篇文章
在这里插入图片描述

c、Basic Graphs图表

在这里插入图片描述

2、CLI命令行运行+HTML报表

这个命令会生成html报表
jmeter -n -t[jmx file] -l [results file] -e -o [Path to web report folder]

a、命令参数详解

-n:在非GUI模式下运行Jmeter

-t:测试文件
要运行的jmeter测试文件(.jmx).
“-t LAST”:将最后加载用过的文件

-l:日志文件,要将样本记录到文件,例如test001.jtl

-e:–报告的ndofloadtests,负载测试后生成报告仪表盘

-o:保存html报告的路径,此文件夹必须为空或者不存在

b、命令行的测试进度报告

在这里插入图片描述
我们通常会在一个linux机器上面去执行

缺点:命令行去运行—推荐的;但是:最终要生成测试结果报告,虽然没有UI界面那么大的消耗,但是依然会有资源压力;
最大的缺点:当测试时间很长时,我们并不能实时的监控

当我们对系统进行12个小时的测试时,但是第1个小时就出现问题,此时并不能看出问题。等12个小时后里面出现几十万次报错,此次测试没用,
测试机器有问题;测试应该停止,而不能继续测试。

3、后端监听器接仪表盘

常用的方案

InfluxDB+Grafana

三、InfluxDB+Grafana Jmeter测试监控大屏

1、整体架构梳理

在这里插入图片描述

2、Linux环境中InfluxDB安装与配置

https://blog.csdn.net/YZL40514131/article/details/134933846

3、JMeter后端监听器链接InfluxDB

a、jmeter配置

在这里插入图片描述

b、influxdb创建对应的数据库

1、第一步:在influxdb服务器上面,输入influx命令进入influx
2、第二步:influx中输入语句:创建jmeter数据库
create database jmeter;
3、第三步:退出influx
quit

在这里插入图片描述
注意事项influxdb与jmeter之间一定要网络互通
如果是虚拟机或者其他linux最好关闭防火墙

4、Linux环境中Grafana环境搭建

a、进入安装包所在目录执行命令

root@hecs-213321:~/performance_testing/monitor# tar -zxvf grafana-9.0.0.linux-amd64.tar.gz 

b、解压

root@hecs-213321:~/performance_testing/monitor# ls
grafana-9.0.0                     influxdb_1.8.0-2_amd64.deb  prometheus-2.36.1.linux-amd64.tar.gz
grafana-9.0.0.linux-amd64.tar.gz  influxdb-1.8.0.x86_64.rpm

c、启动

cd grafana-9.0.0

记得启动相关的命令,在解压后的文件夹里面
例如

root@hecs-213321:~/performance_testing/monitor/grafana-9.0.0# 

d、启动命令

root@hecs-213321:~/performance_testing/monitor/grafana-9.0.0# ./bin/grafana-server web

停止:ctrl+c
关闭ssh窗口,程序就停止了

e、工作中:后台启动

nohup ./bin/grafana-server web > grafana-server.log 2>&1 &

root@hecs-213321:~/performance_testing/monitor/grafana-9.0.0# nohup ./bin/grafana-server web > grafana-server.log 2>&1 &[1] 3481095
root@hecs-213321:~/performance_testing/monitor/grafana-9.0.0# ls
bin  conf  data  grafana-server.log  LICENSE  NOTICE.md  plugins-bundled  public  README.md  scripts  VERSION

f、web访问

http:ip:3000
默认端口3000
默认用户名和密码都是admin

在这里插入图片描述

5、Jmeter - InfluxDB -Grafana完整构建调试

a、添加数据源

选择InfluxDB
在这里插入图片描述
配置InfluxDB地址
在这里插入图片描述
配置InfluxDB对应的表和访问方式
在这里插入图片描述

b、配置大屏数据展示

导入模板
在这里插入图片描述
导入json文件
在这里插入图片描述
配置模板
在这里插入图片描述

6、常见问题

1、网络不通,检查网络IP是否写对,防火墙是否关闭
2、jmeter里面的influxdb地址里面的db=jmeter:和你在influxdb里面创建的数据库一致
3、后端监听器里面measurement:默认携程jmeter和grafana监控大屏模板相对应

在这里插入图片描述

7、优点

横向对比多次性能测试数据
长时间测试,能够实时监控性能测试执行情况

四、性能测试领域细分概念:以目的进行划分

1、基准测试:理论推断

目的:平时负载情况,资源占用情况

2、负载测试:实际性能数据(小规模)

目的:想知道一个系统在多少并发的时候会出现问题,这个问题不只是资源的问题,

基准测试和负载测试共同目的是,探索程序的负载能力

3、压力测试:

取负载测试结果中的最高负载能力-压测
取超出预期负载的测试,看程序的性能反应

4、耐久性测试(疲劳测试)(在压力测试和负载测试之间)

压力测试所持续时间----体现到耐久性
取决于业务场景

生成环境高并发压力,一天中的某几个小时,钉钉打卡(小时为单位,24小时/12小时)
全天都有压力,以天为单位(3天/7天)

5、尖峰测试

模拟突然出现的高并发负载,观察程序在这种情况下出现的反应

在这里插入图片描述
压力测试、耐久性测试、尖峰测试是为了探索程序在高负载情况下的反应

我们作为基准测试,通过基准测试得到负载测试大概率的线程数量通过负载测试,我们可以简单的分析到系统的性能瓶颈达到了,以50ms为响应时间为例,当响应时间小于50ms表示系统性能没有问题。如果超过了50ms代表系统的瓶颈到了,这个时候我就能知道当前线程数为多少。
在这里插入图片描述
接着拿着这个线程数据去做压力测试,观察这10个线程能不能长期稳定的低于50ms。

五、业务流程性能测试

以流程:打开首页——》选择自己喜欢的小说为例

用户真实操作:打开首页(多个接口加载)——》介绍页打开(多个接口加载)
但是:从首页到小说介绍页——》需要用户思考时间
添加定时器
首页与介绍页之间添加1个定时器

在这里插入图片描述

通常用到2个定时器

固定定时器
在这里插入图片描述
统一随机定时器
在这里插入图片描述

携带token的怎么处理?

例如:访问书架接口,有个前提:先登录
前置条件:100个已登录的账户,线程数为1,循环1000次,访问书架
线程组目录如下
操作步骤:
1、新建setUp线程组 - 预先登录100个用户
设置1个线程,循环100次
在这里插入图片描述

在这里插入图片描述
2、添加CSV数据文件设置,提前准备好用户名表
在这里插入图片描述
3、添加登录接口
在这里插入图片描述
4、添加HTTP信息头管理器
在这里插入图片描述

5、添加JSON断言
在这里插入图片描述
6、添加JSON提取器
在这里插入图片描述
JSON提取器提取的数据不能跨线程使用
变量名login_token:不能跨线程组使用

需要用到BeanShell,将login_token保存为全局变量,共享给其他的线程组
这里有100个login_token保存100个全局属性

7、添加BeanShell断言
将Json提取器中的变量设置为全局变量,目的是跨线程组使用
在这里插入图片描述
8、添加调试取样器
JMeter属性设置为True
可以查看jmeter的运行信息,例如设置的全局变量
在这里插入图片描述
在这里插入图片描述

9、添加计数器
记录当前执行的是第几次,并通过 number 变量保存
在这里插入图片描述

10、新增书架接口线程组

在这里插入图片描述
11、线程组下新建HTTP取样器
在这里插入图片描述
12、添加HTTP Cookie管理器
在这里插入图片描述
13、添加HTTP信息头管理器
在这里插入图片描述
14、添加JSON断言
在这里插入图片描述

面试:
当时负责什么模块?怎么设计性能测试用例的?
业务流程怎么测试的?

定时器:用户思考时间

登录接口怎么做的?
模拟多少用户登录?
登录完成后去压测某一个接口
用了哪些组件?
怎么去跨线程组共享变量的?

评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

敲代码敲到头发茂密

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值