性能测试很简单-JMeter性能测试实践

最近破费买了一台阿里云服务器,准备搭建自己的网站,顺便将自己开发的一些测试小工具部署到服务器上,虽然机器配置一般,还是决定对服务器进行压测一番,看一下服务器性能如何。本次压测选择的工具是JMeter,这个工具也是接口测试工具,可以做接口自动化测试。话不多说,开整。

安装Jmeter

JDK

https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

image.png

直接安装dmg文件即可。

JMeter

安装很简单,直接解压官网下载的.tgz安装包就行了

https://archive.apache.org/dist/jmeter/binaries/

启动,有两种方式

  1. GUI启动

进入解压的Jmeter的bin目录,执行./jmeter即可启动

image.png

  1. 非GUI启动
jmeter -n -t xx.jmx -l log.jtl

⚠️压测注意事项:Don't use GUI mode for load testing:不要使用GUI模式进行负载测试。

 

压测准备

服务介绍

http://121.196.172.xxx/?s=%E4%BD%A0%E5%A5%BD,该服务就是一个HTTP请求,Get请求方法。

image.png

服务器配置

配置项

配置值

CPU

Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz

内存

2G

硬盘

40G

操作系统

Red Hat 4.8.5-11

压测任务

简单压测查询服务性能,具体操作开启100个线程对查询接口进行压测15min,观察性能表现。

压测脚本开发

  1. 配置线程组

image.png

  • same user on each iteration:意思是同一个用户发起请求,勾上并不能代表真正意义上的多线程访问。
  • Ramp-up period(in second):例如100个用户,这里配置10,则每秒启动10个用户
  • Loop-count:循环次数,每个线程发送请求的次数。eg:线程数为20,循环次数为5,那么每个线程发送5次请求,总请求数为20*5=100
  1. 开发接口测试请求

image.png

  1. 本地调试

image.png

执行压测

我们设定测试场景为100用户,每隔1秒启动10个新客户;整个测试持续15min。现在,我们切换到性能测试脚本目录下,执行下面的命令启动测试:

jmeter -n -t xxx.jmx -l log.jtl

生成压测报告

jmeter -g log.jtl -o <report folder>

压测结果

服务器监控

先看下服务器监控

image.png

压测结果分析

我们需要先对测试结果做个介绍,查看数据统计图:

image.png

平均响应时间3622ms,吞吐量12.92Tranction/s。

聚合报告参数详解:

  1. Label:每个 JMeter 的 element(例如 HTTP Request)都有一个 Name 属性,这里显示的就是 Name 属性的值
  2. Samples:请求数——表示这次测试中一共发出了多少个请求,如果模拟10个用户,每个用户迭代10次,那么这里显示100
  3. Average:平均响应时间——默认情况下是单个 Request 的平均响应时间,当使用了 Transaction Controller 时,以Transaction 为单位显示平均响应时间
  4. Median:中位数,也就是 50% 用户的响应时间
  5. 90% Line:90% 用户的响应时间
  6. Min:最小响应时间
  7. Max:最大响应时间
  8. Error%:错误率—错误请求数/请求总数
  9. Throughput:吞吐量—默认情况下表示每秒完成的请求数(Request per Second),当使用了 Transaction Controller 时,也可以表示类似 LoadRunner 的 Transaction per Second 数
  10. KB/Sec:每秒从服务器端接收到的数据量,相当于LoadRunner中的Throughput/Sec

吞吐量

image.png

可以看到查询服务的TPS在1分钟内逐渐攀升,最终稳定在13QPS左右。

 

响应时间

image.png

在开始逐渐加压的1分钟内响应时间不断增加,可以结合服务器监控发现,这主要是因为开始加压阶段CPU占用飙升至90%,内存使用也在增加(非主因)导致。随着线程全部开启后,资源消耗相对稳定,响应时间开始逐渐降下来,最终在2000ms左右徘徊。

image.png

75%的事务处理时间都在4755ms以下,整体平均响应时间处于2800ms以下。

结论:在100线程并发场景下,服务器最大QPS可以达到13。

image.png

posted @ 2022-07-24 18:24  QualityAssurance21  阅读(197)  评论(0编辑  收藏  举报