性能场景设计
性能场景设计
一、获取最大并发用户数
1、负载测试：通过负载测试，逐步增加并发用户数，找出我们最大可接受的并发用户数值。
1.1 最大可接受并发用户数 VS 最大并发用户数
1.1.1 最大可接受的并发用户数，一般都不是最大并发用户数
1.1.2 可接受的范围：行业标准 http协议的接口平均响应时间<=1.5s,错误率 <=0.1%
1.1.3 最大并发用户数： 一般是说直接口出现大量失败，或者几乎所有的请求都失败，或者说服务宕机此时的并发用户数；性能测试中一般都用这个作为最大可接受的并发用户数。
1.2 怎么获得最大可接受的并发用户数：用负载测试逐步增加并用户数，然后，查看结果，如果接口出现了在某一段并发用户数相等的时间内，我们的平均响应时间超过1.5s，那就说明这个并发用户 数已经超过了最大可接受并发用户数，或者，我们的错误率超过0.1%，也就是说这个并发用户数，超过了最大可接受的并发用户数。
1.3 操作步骤
1.3.1 设定10个人运行一段时间，结束，然后20个人运行一段时间结束，30 个人运行一段时间，结束...........这种方式太耗费时间
1.3.2 逐步增加人，要连续的增加，从10个人运行一段时间，不停止，继续增加人数，达到20个人，运行一段时间，不停止，继续增加 人。。。。 所有增加人的操作都不做停止。我们要时刻关注，在某一段并发用户数相同的时间内，我们请求的平均响应时间和 错误率。
1.4 jmeter操作：引入插件 jpgc jpgc - Standard Set
1.4.1 Stepping Thread Group 阶梯线程组（负载线程组）
1.4.2 this group will start xxx threads 这个线程组将启动多少并发用户数
1.4.3 Next，add 调整每次递增的步长，我们可以缩短这个找到最大可接受并发用户数 区间
1.4.5 next add xxxx threads every xxxx seconds, using ramp-up xxx seconds：用5秒的时间累加60个并发用户数，然后，运行30s钟，一直这样循环，直到产生期望的最大并发用户数；threads every----30s 一般我们性能测试，一定量并发用户数，只需要几十秒到 几十分钟就可以了。
1.4.6 then hold load for xxx seconds 持续运行多少时间
1.4.7 finally stop xxx threads every xx second 最后每隔多少时间停止多少个线程。
注意：在负载场景设计时候，我们遵循，缓起步，快结束，原则，但是快结束，并不是瞬间结束。
1.5 实操（GUI图形界面）
1.5.1 监听器：Active Threads Over Time 随着时间变化的活跃线程数；Response Times Over Time 随着时间变化的响应时间；Transactions per Second TPS
1.5.2 分析：Response Times Over Time响应时间的图，在1分15秒到1分45秒时间内，平均响应时间小于1.5秒，在1分46秒至1分57秒，响应时间已经超过了1.5秒；活跃线程数图1分15秒到1分45秒，活跃线程数为30个并发用户数，1分46秒至1分57秒，活跃并发用户数为40，所以我们初步判断最大可接受的并发用户数在【30,40】区间内；tps图，在整个过程中，没有看到错误。在整个过程中，tps的平均线，都维持一致。得到的结论是，错误率<0.1%，所以，最终，我们判断的最大可接受并发用户数的范围在 [30,40]
1.5.3 再次用30到40并发用户步长为1进行测试：通过图形界面可以看出当并发数在34的时候，平均响应时间达到1.5秒，所以通过两轮负载测试可以得出此接口的可接受最大并发用户数大概为34
1.6 实操（CLI命令）
1.6.1 使用CLI无图像界面，我们脚本中所有的监听器，都禁用
1.6.2 进入jmeter的bin文件夹，cmd回车，执行cli命令jmeter.bat -n -t +脚本地址+脚本名+ -l jtl文件地址 + -e -o 报告地址（jmeter.bat -n -t VIP15/混合场景.jmx -l VIP15/jtl/hunhe001.jtl -e -o VIP15/report/hunhe001）
1.6.3 通过cli命令，我们可以明确的看到在32个并发用户数时，我的平均响应时间小于1.5s， 33个时，平均响应时间超过了1.5s，错误率一 直都是0.00% ，所以，我们得到最大可接受的并发用户数是32
注意：我们做性能测试需要多执行几轮，用多次结果，来综合分析。但是不可以连续执行多次，需要等服务器资源得到释放，恢复正常后才可以执行下一轮
1.7 总结：真正的性能测试中，使用CLI无图像界面命令来执行性能测试。cli命令中 Active: 32 Started: 32 如果Active=Started说明我们当前的机器可以产生你想要并发用户数，运行过程中如果Active !=Started 不一 致，那么很可能是你的机器产生不了你期望的并发用户数。解决办 法： 可能要增加slave机器
二、性能测试场景设计
1、并发用户数：就是我们上面通过负载测试得到的最大并发用户数32，在jmeter中为线程数
2、ramp-up时间： 用多少时间去产生线程数，就是在这个时间点结束的时候，产生你设置的线程数
2.1 我们jmeter做http协议的性能测试，一般情况下，一台电脑，只能产生 1.5k-2k左右的并发用户数。
2.2 但是jmeter工具本身没有并发用户数的限制，这个1.5k-2k左右并发用户数，与你的jmeter电脑的硬件配置，关系 不大，你增加cpu、内存，并不一定能提高这个数字。因为，这个数 字与你的jmeter电脑的端口、被测服务器的性能有关系。
2.3 ramp-up时间与线程数，在并发用户数小于几百时，ramp-up时间设置在3秒以内，几百到上千 ramp-up时间5秒左右
3、循环次数：默认1
3.1 每个线程数，至少会运行1次
3.2 实际的性能测试中，我们一般不会直接设置这个循环次数，而是，勾选循环次数为永远 + 调动器设置持续运行时间
3.2.1 如果仅仅勾选永远，那么，就会一直请求下去，直到你点击停止才会停，点击停止，导致的可能的异常，也会被记录到失败率中，所以，我们一般，也不会只勾选永远。
注意： 循环次数如果没有勾选永远， 调度器就不生效
3.2.2 ramp-up 时间小于持续运行时间，最后总的运行时间是持续运行时间；ramp-up 时间大于持续运行时间， 我们的运行时间一般会是ramp-up时间减1；所以，我们有效的设置，一般是持续运行时间大于ramp-up时间。
4、HTML报告：
4.1 报告中的数据默认是1分钟获取一个点，我们在性能测试中，如果你的执行时间比较短，那么，我们需要去修改我们默认获取点的时长。修改配置文件reportgenerator.properties：jmeter.reportgenerator.overall_granularity=6000 设置大于1000的数字
4.2 用cli命令执行的时候出现：Tidying up ... @ Fri Apr 22 21:33:42 CST 2022 (1650634422494) ... end of run，这个一段信息是说，现在正在进行数据处理，jtl文件正在转换为html报告，.. end of run 说明html报告已经生成，在用分布式的时候，这个.. end of run 可能会要等很长时间，因为这个要对jtl文 件进行大量计算。所以，我们一般把主控的机器的内存配置的比较大，目的是加快 jtl转换为html报告的速度。 如果你等待很久时间都没有出结果，你可以执行： shutdown.cmd、shutdown.sh
5、GUI聚合报告
5.1 局限性1：GUI聚合报告只有在并发用户数不发生变化的时候才可以看：因为，我们的聚会报告中的数据，是平均值，不能体现，不同数量的人的指标值
5.2 局限性2：聚合报告只有在没有网络瓶颈时才可以看，这两个条件，有任何一个不满足，都不能看聚会报告。所以负载测试绝不可以看GUI聚合报告
5.3 聚合报告中，我们通常会用吞吐量的数值来表示tps的数值。其中90% 95% 99% 都是说在总的请求样本中，有90% 95% 99%的样本的响应时间 是小于等于这个时间
三、压力测试场景
1、用普通性能线程组，持续运行时间设置一个小时为单位的时长
2、阶梯也可以只需要把持续运行时间设置比较长
四、有时间规律的场景
1、背景：我们的产品，有时间性的这种高并发，在某些时候，请求量很少，而在某 一些时候，又请求量很高。比如打卡系统，点餐系统等
2、使用线程组：Ultimate Thread Group 终极线程组
2.1 我们期望出现多个波段，那么我后一个波段的起始时间，应该大于等于上 一个波段的结束时间。 初始化时间 >= sum(上一行所有时间)
3、需求场景
3.1 模拟一天订餐系统的访问情况(点餐高峰期存在两个时间段，上午10:30-中午13:00，下午5:00-7:00)，第二个开始时间要在第一个高峰后间隔几十秒-----相同人数
3.2 需要模拟，在不同的时候，不同的人请求相同的接口
3.3 设计一个不定步长的阶梯场景
3.3.1 初始化的时间 = sum(上一行初始化时间+起步时间+ 你期望的运行时间)
3.3.2 hold时间 = sum(上一行所有时间) - sum(当前一行的时间)
五、面向目标场景
1、背景：在企业中，性能需求，有时会直接要求我们接口要能支持500并发用户数，或者直接说，我们的接口要支持80tps。
2、使用线程组
2.1 Arrivals Thread Group 面向多少tps的线程组：ramp-up time： 启动时间，ramp-up step： 步骤
2.2 Concurrency Thread Group 面向多少并发用户数线程组：ramp-up time： 启动时间，ramp-up step： 步骤
3、性能测试中可能遇到的问题：设置的时间已经到了，但是，我们脚本并没有结束，并发用户数也没有清零。
3.1 原因：一是可能发起方的内存不足，二可能项目问题
3.2 解决：强制关闭、 执行shutdown，但是强制关闭后的数据会存在误差
3.3 在真正测试过程中，遇到这种情况，对于数据的处理方法
3.3.1 丢弃这次测试结果，重新进行测试
3.3.2 丢弃最后的测试数据
3.3.2.1 cli命令做性能测试，一般，我们会生成一份jtl文件，删除jtl文 件中最后的一些数据，重新生成测试报告，两种方法重新生成数据分析结果：1、jmeter -g xxx.jtl -o report；2、jmeter中添加聚合报告，选择文件打开
六、混合场景
1、测试场景：在负载测试、性能测试、压力测试、有时间规律、面向目标等性能场景做完以后才开始做混合场景
2、定义：不同数量的并发用户数，对不同的接口发起请求，不可以用一个线程组，需要用到多个线程组
3、难点：每个接口的并发用户数定义为多少，他们的比率关系是多少
3.1 这个并发用户数，不是用每个接口的最大可接受并发用户数
3.2 每个接口并发用户数的确定，是根据生产环境业务分配的比例来进行粗略的估算出来 的。
4、两种技术来实现混合场景：
4.1 属性方法：属性可以跨线程组
4.2 数据库转接：混合场景要用多个线程组，jmeter中参数，是不能直接跨线程组传参。
