【性能测试场景:负载,监听,压测,并发】

时间:2023-02-01 12:21:39

一、普通性能场景

普通线程组设置并发用户数

【性能测试场景:负载,监听,压测,并发】

线程数:需要设置的并发用户数
并发用户数: 受cpu的主频、分配的内存大小、操作系统(允许打开文件数量、开放的端口数量)的影响,一台电脑,大概能支持 1500并发用户数以内(http协议)

ramp-up时间: 在多长时间内启动所有的线程。
注意:只是说明,在第n秒结束时,会产生m个并发用户数,并不代表每秒会产生多少个并发用户数
已经产生的并发用户数,就会调用 取样器,进行请求。请求循环次数用完,这个并发用户数的资源就会释放,这个并发用户数就会消失。


循环次数:

  • 最少为1。
    没有勾选“永远”,就是每个并发用户都会循环的次数
  • 勾选 “永远” 不配置其他, 一直运行下去,直到点击 ‘停止’才会停止
    手工点击停止,会导致不可中断的请求被强行停止而报错,所以 一般不会只勾选永远,会配合调度器一起使用


调度器:

要想调度器生效,一定要勾选永远。
持续运行时间: 会一直运行多长时间后自动结束

接口性能测试: 一般的标准是,响应时间要小于1.5s秒

1.5s的来由: 性能测试行业标准 Apdex

  • 500ms以内是满意
  • 500ms ~ 1.5s内 能接受
  • 大于1.5s不能接受


二、负载测试---阶梯场景

负载测试: 逐步增加并发用户数,找到我们的最优并发用户数的区间

最优并发用户数:接口未大量报错且平均响应时间在目标时间内的最大并发用户数

使用线程组:jp@gc stepping thread group

plugin manager下载插件: jpgc "apply changes and restart jmeter"

【性能测试场景:负载,监听,压测,并发】


监听器

活跃线程数Active Threads Over Time

【性能测试场景:负载,监听,压测,并发】


响应时间图Response Times Over Tim

【性能测试场景:负载,监听,压测,并发】


tps图Transactions per Second

【性能测试场景:负载,监听,压测,并发】


获取最大(最优)并发用户数的方法

1、先设定一个比较大的范围值 普通线程组+ 聚合报告执行较短时间,通过聚合报告中的,异常率 + 平均响应时间来判断。

  • 如果异常率为0, 就看平均响应时间,有没有超过目标值(1.5s),说明猜测的并发数少于可能的实际值
  • 如果时间已经超过了说明猜测的并发数大于可能的实际值
  • 如果平均响应时间很小,说明并发用户数还可以调整很大, 可以看吞吐量的值,大概估计最大并发用户数可以达到吞吐量的数字

2、设定合适的步长,运行一轮 阶梯场景 观察tps图中是否有报错、在某一并发用户数范围的时响应时间,与目标响应时间对比, 从而找到一个最大并发用户数的区间。
3、缩小范围,设定 起始值、最大值为上一步的区间值,步长根据实际情况来设定 首先看 tps 有没有错误(连续性报错),如果连续报错,说明此时的并发用户数已经超过了最大并发用户数 没有错误,就看响应时间图 ,看平均响应时间符合目标值的时间点,然后对照活跃线程数Active Threads Over Time,同样的时间点的活跃线程数,就为最大(最优)并发用户数


三、压力测试场景

用一定量的并发用户数,持续运行一段比较长的时间,来看服务器的稳定性。

关键点:一定量的并发用户数,运行时间要比较长

压力测试场景流程

1、负载测试-阶梯场景,找到最大并发用户数
2、最大并发用户数进行普通性能场景测试
3、如果出现服务不稳定的情况,再进行压测试场景


四、波浪型

请求会在一段时间集中爆发,然后趋零,然后再爆发的周期性请求场景,有时间规律的请求

外卖,饭点请求很多,然后降低,下一个饭点请求很多,周期性 使用线程组:Ultimate Thread Group

【性能测试场景:负载,监听,压测,并发】


关键点:下一个波浪的起始时间,大于等于上一个波浪的所有时间之和

五、混合场景

定义:不同数量的并发,对不同接口向服务器发起请求,模拟真实的请求场景

要点

  • 不同数量的并发:线程组才能设计不同数量的人, 所以需要有多个线程组
  • 多个线程组,跨线程组传参
    - 设置和调用属性方法
    - 文件嫁接
    - jdbc数据存储
  • 多个线程组,可以使不同类型的线程组
    举例(登录,查看商品列表,下单)每个接口的访问量不同 设置3个线程组,分别对应3个接口,设置不同的线程数模拟并发 接口间通过合适方式进行传参,实现功能的正常 分析每一个接口的测试结果


六、面向目标测试场景

面向TPS

期望某个接口系统的处理能力不低于 200 次/秒,问你,这样的场景,你如何设计?

类似场景:秒杀,模拟服务器要能在1秒钟处理1000个事务,实际上是要求tps大于等于1000就可以了

利用插件管理器,下载 jpgc 插件。然后添加 bzm - Arrivals Thread Group 线程组

【性能测试场景:负载,监听,压测,并发】


使用说明

  • target rate:目标,每秒钟多少个请求数
  • ramp up time(sec):达到目标需要的时间
  • ramp-up steps count:达到目标需要多少步
  • hold target rate time(sec):保持目标时间
  • thread iterations limit:线程迭代次数限制,如果我们只需运行每个用户一次以模拟用户的实际行为,则设置为1;设置为空,表示每个用户将运行不确定的迭代,直到调度结束。
  • log threads status into file:将线程状态记录到文件
  • concurrency limit:最大并发数限制

对照监听器,查看达到设定tps,稳定运行状态的接口响应时间,以判断是否满足要求


面向并发用户数

Concurrency Thread Group

【性能测试场景:负载,监听,压测,并发】


使用说明:

  • 目标并发(线程数)
  • 加速时间(整个测试)
  • 加速步骤计数
  • 保持目标并发时间(时间单位 - 分钟或秒钟)
  • 线程迭代次数限制(循环次数)
  • 将线程状态记录到文件(将线程启动和线程停止事件保存为日志文件)

实际使用阶梯线程组并无太大区别