JMeter - Linux环境压测以及HTML图形化报告

JMeter - Linux环境压测以及HTML图形化报告

1.Linux环境压测

1.1 打包部署API服务

 之前我们在本地使用Spring Boot编写并且调试了一个API服务,这里我们将其打包部署到Linux服务器上运行。我们在项目所在目录下利用mvn clean package命令即可打包项目。看到下图中BUILD SUCCESS即打包成功。
在这里插入图片描述
 这里我们找到项目target目录下springboot-jmeter-0.0.1-SNAPSHOT.jar即是我们需要使用的jar包。
在这里插入图片描述
 这里我们将打好的jar包放置服务器中/home/app/目录下。通过nohup java -jar springboot-jmeter-0.0.1-SNAPSHOT.jar &可以使其作为守护进程方式后台启动。这里我们根据{ip}:{port}/stars的方式可以去访问我们的API服务了。如果服务启动成功无法访问,可自行查看防火墙规则是否放开。
在这里插入图片描述
在这里插入图片描述

1.2 下载安装JMeter

 Linux下载安装JMeter也比较简单,我们可以通过wget http://apache.osuosl.org/jmeter/binaries/apache-jmeter-5.1.1.tgz或者通过其他方式下载之后上传到指定目录即可。这里我们准备好安装包后通过tar -zxvf apache-jmeter-5.1.1.tgz解压后即可。
在这里插入图片描述

1.3 CLI命令行模式参数介绍

 我们在【JMeter官网文档】中可以找到下面一段信息,这里面就包含了非GUI界面命令运行测试脚本时可以携带的参数。这里做一个简单的介绍,更详细的大家根据需要自己查阅。
在这里插入图片描述

  1. -h/-help:相关帮助
  2. -n:非GUI模式启动,即命令行模式启动(Command LIne Mode)
  3. -t:指定运行所使用的JMeter jmx脚本文件
  4. -l:记录测试结果jtl文件,需保证指定文件不存在
  5. -r:指定远程服务器
  6. -e:测试脚本执行后生成对应的HTML报告
  7. -o:指定存放HTML报告目录,需保证目录不存在或为空目录

1.4 Linux CLI压测操作

 这里我们通过之前GUI界面配置的对/stars接口的测试计划保存为server_.jmx文件。
在这里插入图片描述
 这里我们需要打开JMX脚本文件修改以下对应的IP为我们部署API服务的地址。这里我们API服务和JMeter服务放在同一台机器上,直接使用127.0.0.1即可。
在这里插入图片描述
 这里我们将JMX文件上传至JMeter安装目录下,并新建jtltemp两个空目录用于存储测试结果。
在这里插入图片描述
 我们通过运行./jmeter -n -t /usr/apache-jmeter-5.1.1/server_.jmx -l /usr/apache-jmeter-5.1.1/jtl/result.jtl -e -o /usr/apache-jmeter-5.1.1/temp命令,就可以看到几个我们十分熟悉的数据了。
在这里插入图片描述
 我们将jtl目录下生成jtl文件下载到本地,通过JMeter GUI聚合报告/汇总报告都可以导入更加直接清晰地查看测试结果。另外我们还指定生成了HTML文件,下面会单独介绍。
在这里插入图片描述

1.5 JMeter压测性能优化

 这里稍微介绍一些减少资源消耗的建议,可以使压测结果更正确。我们在官方文档里面也可以看到下面这些话。在这里插入图片描述

  1. 使用CLI模式:jmeter -n -t test.jmx -l test.jtl,GUI模式渲染图形会消耗一定性能(CPU、内存等都会受到影响)
  2. CLI模式下尽量不使用Listener监听器(查看结果树、查看结果等),可以通过-l参数禁用
  3. 非GUI模式下尽量不要使用
  4. 不使用功能模式,使用CSV输出而不是XML
  5. 仅保存需要的数据,尽可能少使用断言,过多的断言会对测试过程造成大量的性能消耗
  6. 尽可能使用内网压测,可以避免带宽影响给压测结果带来的影响
  7. 进行大流量压测时,可以多使用几个节点采用分布式压测的方式进行压测汇总

2.HTML图形化报告

 之前我们在Linux环境下进行了一次压测操作,指定了生成HTML图形化报告,这里我们Download下来打开就能看到一个十分舒爽也很直观的页面。这里我们对这里面的内容进行一个介绍。

2.1 Dashboard

 首先默认的话是先展示Dashboard这个模块的数据。
在这里插入图片描述
 这里第一部分就是Test and Report informations测试记录的基本信息,里面主要包括:

  1. Source file:jtl文件名
  2. Start Time:压测开始时间
  3. End Time:压测结束时间
  4. Filter for display:过滤器


 第二部分APDEX(Application performance Index)即应用程序性能指数,主要包括:

  1. Apdex:应用程序性能指标(0~1),1表示所有用户请求均满意,反之0则表示均不满意
  2. T(Toleration threshold):可接受阈值,即用户可接受阈值
  3. F(Frustration threshold):不可接受阈值,即用户不可接受响应时间
  4. Lable:采样器名称


 这里我个人理解当所有请求均在T范围内,则Apdex性能指标为1;均在F范围外,则Apdex性能指标为0;各区域均有分布,则Apdex性能指标根据具体各区间比例计算得出。


 第三部分就是右下角的饼图Requests Summary请求概要,这里只有两个内容:

  1. OK:成功
  2. KO:失败
    在这里插入图片描述

 我们再往下拉,这里所呈现给我们的数据统计我们就是十分熟悉了,我们之前在【JMeter - 核心组件以及自定义参数】-聚合报告分析中已经对这些统计数据进行了介绍,这里再稍微提及一下。
 同样第一部分Statistics统计数据,比较核心的一些数据统计,主要包括:

  1. Label:Sample采样器名称
  2. Samples:总共发送请求数(线程数 * 循环次数)
  3. KO:失败次数
  4. Error%:请求失败率
  5. Average:平均响应时间
  6. Min:最小响应时间
  7. Max:最大响应时间
  8. 90%Line:90%线,90%用户响应不超过该时间
  9. 95%Line:95%线,95%用户响应不超过该时间
  10. 99%Line:99%线,99%用户响应不超过该时间
  11. Throughput:吞吐量,一般情况下可看做每秒完成请求数(和QPS类似)
  12. Received:每秒从服务器端接收到的数据量
  13. Sent:每秒从客户端发送的请求的数量


 第二部分Errors以及第三部分Top 5 Errors by sampler主要就是统计请求出现错误以及TOP5发生错误的采样器信息,这里我们全部通过,所以不会有统计。
在这里插入图片描述

2.2 Charts

 接下来我们来看下Charts图表相关的模块。
在这里插入图片描述
 这个模块主要包括三部分:Over Time(随着时间变化相关)Throughput(吞吐量相关)Response Times(响应时间相关)。我们对每个部分进行单独介绍。这里因为我只做了简单少量的压测请求,所以结果可能和实际的有比较大的出入,只是为了介绍下整个HTML可视化报告的内容,大家可以自己调整压测配置获取更加真实的数据。

2.2.1 Over Time

 这一块主要是关于随着时间变化一些指数数据所产生的变化,最开始Test and Report informations和之前一样不做过多介绍。
 首先是Response Times Over Time,即响应时间随时间变化趋势。由于应用需要初始化建立连接以及CPU、内存等分配都会消耗资源,随着系统趋于稳定,响应时间也会趋于稳定。
在这里插入图片描述
Response Time Percentiles Over Time (successful responses),这个图表用来表示最大、最小、各个用户响应时间分布的变化趋势。
在这里插入图片描述
Active Threads Over Time,活跃线程变化趋势,即并发用户数趋势。相当于我们模拟的并发用户发出请求随着时间变化的趋势。
在这里插入图片描述
Bytes Throughput Over Time,即每秒接收和请求字节数时间变化趋势,蓝线表示发送字节数,黄线表示接收字节数。
在这里插入图片描述
Latencies Over Time,平均响应延时随时间变化趋势
在这里插入图片描述
Connect Time Over Time,即连接耗时变化趋势。
在这里插入图片描述

2.2.2 Throughput

 这一部分的内容大体都是和反应服务吞吐量有关的图表。在整个压测结果中也是比较重要的一部分。
Hits Per Second,即每秒请求数量。
在这里插入图片描述
Codes Per Second ,即每秒响应状态码数量,这里主要是对200响应成功的状态码进行记录统计。
在这里插入图片描述
Transactions Per Second,即每秒事务数,也就是我们熟悉的TPS。这里因为我们没有开启事务,故TPS也可看做QPS。在这里插入图片描述
Response Time Vs Request,即响应时间和请求数对比关系,这里我们请求数量太小所有只有两个散点。
在这里插入图片描述
Latency Vs Request,即延迟时间和请求数量对比关系。
在这里插入图片描述

2.2.3 Response Times

 最后一部分就是和响应时间相关的一些数据统计,可以很清楚地反应响应时间在整个压测过程中的变化。
Response Time Percentiles,即响应时间百分比,通过之前压测数据中所有响应时间统计分析所展示的。可以更详细看出自己所需要了解的百分线用户的响应时间。
在这里插入图片描述
Response Time Overview,即响应时间概述。大家仔细看这种那个图不难发现,横坐标所绘制的区间和我们最开始看到的APDEX应用程序性能指数中划分的区间一致。
在这里插入图片描述
 Time Vs Threads:即活跃线程数和响应时间对比关系,这里同样由于数据较少的原因造成结果不是十分明显。
在这里插入图片描述
Response Time Distribution,即响应时间分布图。
在这里插入图片描述
 可以看到,通过HTML可视化报告我们能够更加清晰、详细地了解到整个压测过程中应用性能指标的变化以及相应的数据统计分析。我们可以通过报告中给我们呈现的结果,对应用服务进行针对性的优化,让我们的服务更加稳固并且提供更好的体验。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值