Jmeter 性能测试

为什么需要性能测试

  • 实际业务,用户量大,消耗系统资源
  • 有些bug,必须并发才能测试(如电商-秒杀)
    本质上是模拟多个用户同时在线-接口并发请求

常见的一些性能测试指标

什么是性能测试

观察系统在一个给定的环境和场景中的性能表现是否与 预期目标一致,评判系统是否存在性能缺陷,并根据测 试结果识别性能瓶颈,改善系统性能的完整的过程。

性能测试策略

  • 负载测试 – Load Testing 在一定的软件、硬件及网络环境下,通过改变系统负载方式、增加负载 等来发现系统中所存在的性能问题。
    用于确定系统所能承载的最大用户数、最佳用户数。关注不同用户数下的系统响应时间及服务器的资源利用率。

  • 压力测试 – Stress Testing 在一定的软硬件及网络环境下,通过模拟大量的虚拟用户向服务器产生 负载,使服务器的资源处于极限状态下长时间连续运行。
    目的测试服务器在高负载情况下是否能够稳定工作,挖掘系统最脆弱的位置。

  • 稳定性测试-- Stability Testing 在一定的软件、硬盘及网络环境下,模拟一定数量虚拟用户运行一种或多种业务,长时间的运行(7*24小时)系统。
    目的是检测系统在长时间运行下的稳定性和性能相关指标是否符合预期。

  • 基准测试-- Benchmark Testing 在一定的软件、硬盘及网络环境下,模拟一定数量虚拟用户运行一种或 多种业务,将测试结果作为基线数据。

在系统调优或者系统评测过程中,通过运行相同的业务场景并比较测试 结果,确定调优是否达到效果或者为系统的选择提供决策数据。

如何评价系统性能?

  1. 用户(End-User)视角
  • 响应时间(Response Time)
  1. 运营商和开发商(Customer)视角
  • 响应时间(Response Time)

  • 并发用户数(The Number of Concurrent Users)

  • 吞吐量(Throughput) – 每秒交易数(Transaction per Second)

  • 资源利用率(Hardware/Software Resource Utilization)

响应时间(Response time)

响应时间就是用户感受软件系统为其服务所耗费的时间,对于网站系统来说,响应时间就是从点击了一个页面计时开始,到这个页面完全在浏览器里展现计时结 束的这一段时间间隔。

响应时间:2-5-8原则 • 当用户在2-5秒之间得到响应时,会感觉系统的响应速度还可以;

  • 当用户在5-8秒以内得到响应时,会感觉系统的响应速度很慢,但是还可以接受;
  • 而当用户在超过8秒后仍然无法得到响应时,会感觉网站奥特慢了。

吞吐量(Throughput)

指的是在单位时间内客户端和服务器成功传送数据的数量

举例:下载文件,首先向服务器发送下载请求,服务器会返回下载结果和下载文件,这个过程产生的数据就是吞吐量,吞吐量越大下载数据就越快。
注:不是鼠标点击数

资源使用率(Resource utilization)

常见的资源有:CPU占用率、内存使用率、磁盘 I/O、网络 I/O。

每秒点击数(Hits per second)

指客户端每秒钟向服务器端提交的请求数量,如果客户端发出的请求数量越多, 与之相对的平均吞吐量也应该越大。

并发用户数(Concurrent users)

指在客户端的一批用户同时执行一个操作的数量。并发数反映了软件系统的并发 处理能力。
两种错误理解:1.使用系统的全部用户的数。2.用户在线数量

事务(Transaction)

在web性能测试中,一个事务表示一个“从用户发送请求->web server接受到请求,进行处理-> web server向DB获取数据->生成用户的object(页面),返回给用户”的过程,一般的响应时间都是针对事务而言的。

TPS(transaction per second)

每秒钟系统能够处理的交易或者事务的数量.它是衡量系统处理能力的重要指标.

吞吐量(Throughput)

  • 指的是在单位时间内客户端和服务器成功传送数据的数量 .
  • 举例:下载文件,首先向服务器发送下载请求,服务器会返回下载结果和下载文 件,这个过程产生的数据就是吞吐量,吞吐量越大下载数据就越快。
  • 注:不是鼠标点击数

普通的场景设计(普通线程组)

image-1653808722251

线程属性值

设置的线程属性值是【预期压力值】
而聚合报告是【压力测试的实际结果】

线程数

Jmeter java进程下启动的线程,用来模拟真实用户数,1线程数 = 1用户数
windows下,2g的 java内存,1m 的栈空间,最大启动线程数=1000
Linux下,2g的 java内存,1m 的栈空间,最大启动线程数=2000
在Jmeter中,先启动线程,再运行线程,后释放线程【启动线程并运行,释放线程】
线程数建议不超过1000

Ramp-Up时间(秒)

预期线程组的所有线程从启动-运行-释放的总时间
ramp up=0时,表示瞬时加压,启动线程的时间无限趋近于0
特别注意:在负载测试的时候,尽量把ramp up设置大一些,让性能曲线平缓,容易找到瓶颈点

循环次数

每个线程循环执行的次数,默认一次【便于理解:线程的迭代次数、重复发起请求的次数】
如果设置为永远,那么 jmeter 将以最大的可能去发送请求,以此测试出最大并发数

Ramp-up 设置注意事项

Ramp-up需要设置足够长的时间来避免在测试刚开始时工作量过大
假如需要大量线程的话,不建议设置成0,0 属于瞬时加压【过小的 ramp-up period 】
如果设置 0,Jmeter 将在测试开始时就启动全部线程并立即发送请求,这样很容易让服务器达到饱满状态,且瞬间会增加很大的负载量,容易让服务器超载,这样是不合理的;
不合理的原因并不是因为平均压力值过高,而是因为所有线程都在初始状态时一起并发访问,从而引起不正常的初始访问峰值,可以通过 Jmeter 的聚合报告看到这种情况

Ramp-up还必须足够短,保证最后一个线程在第一个线程完成之前开始运行
如果 Ramp-up 过大,则会降低访问峰值的负载,即没有达到预期的压力峰值,无法获取准确的服务器最大负载情况【过大的 ramp-up period 】
具体的表现为:一些线程还没有启动,初期启动的部分线程已经结束了【导致实际并发量并会小于预期并发量】

如何确定一个合理的ramp-up period

首先,让初始点击率接近平均点击率,前提是确定合理的访问量
初始的 ramp-up period = 平均点击率= 总线程/点击率;假如线程数=100,点击率=10次/s,则ramp-up period = 100/10 = 10s

调度器Specify Thread Lifetime【scheduler】

调度器的作用:控制每个线程组运行的持续时间以及它在多少秒后再启动
Duration (seconds) :持续时间;线程组运行的持续时间
Startup Delay (seconds):启动延迟;测试计划开始后,线程组的线程将在多少秒后再启动运行
调度器和循环次数的关系
循环次数有固定值且 ≠ -1,持续时间不会生效,以循环次数为准
循环次数设置为永远或 -1 时,持续时间才会生效
调度器注意事项
当线程组运行完持续时间后,会逐步释放线程,不会一下子把所有线程释放掉,而释放线程也是需要时间的~
所以测试计划总的时间(右上角的时间)会 > 持续时间+启动延迟

TPS

  • 总的完成请求数 = 线程总数 * 循环次数
  • 平均TPS = 总请求数 / 线程运行总时间【上图,右上角黄色三角形的时间】
  • 平均TPS(即聚合报告的TPS)是仅供参考的
  • 实际的TPS是由服务器决定的,因为它是衡量服务器处理能力的性能指标
    image-1653809184054

负载场景的设计

测试计划–添加线程组-选择jp@gc - Stepping Thread Group (deprecated)

image-1653809353899

  • this group will start:表示总共要启动的线程数;若设置为 100,表示总共会加载到 100 个线程
  • first,wait for:从运行之后多长时间开始启动线程;若设置为 0 秒,表示运行之后立即启动线程
  • then start:初次启动多少个线程;若设置为 0 个,表示初次不启动线程
  • next add:之后每次启动多少个线程;若设置为 10个,表示每个梯次启动 10 个线程
  • threads every:当前运行多长时间后再次启动线程,即每一次线程启动完成之后的持续时间;若设置为 30 秒,每梯次启动完线程之后再运行 30 秒
  • using ramp-up:启动线程的时间;若设置为 5 秒,表示每次启动线程都持续 5 秒(和基础线程组的ramp-up一样意思)
  • then hold load for:线程全部启动完之后持续运行多长时间,如图:设置为 60 秒,表示 100 个线程全部启动完之后再持续运行 60 秒
  • finally,stop/threads every:多长时间释放多少个线程;若设置为 5 个和 1 秒,表示持续负载结束之后每 1 秒钟释放 5 个线程

线程组添加监听器:

实例:
image-1653810388376

监听器之jp@gc - Response Times Over Time

即TRT:事务响应时间
性能测试中,最重要的两个指标的另外一个。该插件的主要作用是在测试脚本执行过程中,监控查看响应时间的实时平均值、整体响应时间走向等。
image-1653811086455

jp@gc - Actiive Threads Over Time

不同时间活动用户数量展示
image-1653811108843

jp@gc - Transactions per Second ,即TPS:每秒事务数

性能测试中,最重要的2个指标之一。该插件的作用是在测试脚本执行过程中,监控查看服务器的TPS表现————比如整体趋势、实时平均值走向、稳定性等。
image-1653811121786

待续

上一篇 下一篇

评论 | 0条评论