前言
jmeter单场景设计,一般性能需求场景设计
- 性能需求1:在一定的用户数到访问下,要求响应时间是不是在规定的时间内,而且错误率是不是在规定的范围之内,如:要求能支持5个用户的访问,响应时间在100ms以内,错误率不超过2%
- 性能需求2:要求响应时间在一定的范围内的情况下,能支持最大的用户数是多少,如:要求访问响应时间在3s内的,最大能支持多少个用户并发
单场景设计
1.性能需求1
要求能支持5个用户的访问,响应时间在100ms以内,错误率不超过2%
-
添加线程组,设置线程数是5,ramp-up时间5s,循环次数够选永远,持续时间添加20s
-
添加http请求
-
添加监听器,添加三个监听器,响应时间的监听器,线程数的监听器,聚合报告
-
jp@gc – Active Threads Over Time:活跃的线程数的监听器
- jp@gc – Response Times Over Time:响应时间的监听器
-
聚合报告
-
查看结果
-
查看线程数的监听器,从线程数的监听器中可以看出,差不多4s多一点把5个线程数全部起起来,到了19s多左右开始释放线程,而我们需要参考的数据就是两个绿线直接的数据,也就是4s-19s直接的数据
-
响应时间的监听器,在响应时间的监听器中,在4s多到19s多左右之间的响应时间,低于100ms的属于正常的响应,超过100ms的就不满足本次的性能要求,如果在100ms以内但是响应波动比较大,也是需要重点关注
-
聚合报告,查看错误率是否满足,还有95%的响应时间是否满足需求,从图中可以看出虽然错误率是0,但是95%的平均响应时间是290ms,超过了100ms的要求,不满足性能要求
-
分析性能为什么不满足要求,是本地的负载机,还是服务器,应用服务器,数据库服务器,缓存服务器,到问题影响
性能需求2
要求访问响应时间在5s内的,最大能支持多少个用户并发,需要预估一个用户数,比如:100个用户,如果预估到这个用户测试完的结果还可以,就继续往上加用户数,这里加用户数有两种加法
-
通过二分查找计算最大并发,每次加的用户数是上一轮用户的一半在加上上一轮的用户数,进行递增,如果在当前这次测试后发现不满足性能要求,或者出现性能瓶颈,这时候就开始减少用户数,进行递减,用当前的用户数和上一轮的用户数取中间的那个数,最终测试的结果满足当前要求的那个用户数就是最大用户数
-
第一轮用户数100个
-
第二轮用户数就是100+100/2=150
-
第三轮用户数就是150 +150/2=225,假设这一轮测试结束后,发现不满足性能要求,下一轮的用户数计算:(225-150)/2+150=187.5=188,大约是188个用户
-
第四轮用户数(225-150)/2+150=187.5=188,大约是188个用户,如果这时候还是不满足要求,就继续折中
-
第五轮用户数 (188-150)/2+150=169,如果这时候测试的结果满足性能要求,那169就是最大并发
假设从50个用户开始:
第一轮的截图:50个用户数后没有出现错误率,响应时间95%,5s左右满足性能要求,第二轮增加到75个
第二轮截图:75个用户数,也满足性能要求,第三轮增加到113个用户
第三轮截图:113个用户,虽然响应时间在5s以内,但是聚合报告已经出现错误率,而且95%到响应时间超过7s,这时候假设已经不满足我们的性能要求,然后开始递减用户数,第四轮用户数从75-113中间的数,也就是96左右
第四轮截图,96个用户数,这次没有出现错误率,但是95%到响应时间还是超过了5s,所以还是不满足要求,继续递减,第五轮用户数从75-96中间的数,也就是86左右
第五轮截图:86个用户数,这次出现错误率但是在接受范围之内,但是95%到响应时间在5s,所以满足要求,大概到最大并发就是86个用户数
- 通过逐步加压对过程更准,需要安装逐步加压线程组插件,原有的线程组虽然也可以设置在一定时间增加多个线程,比如10s内增加到100个线程,看上去是平均每秒增加10个,但是实际是10s内增加到100个,并不一定是每秒增加10个
所以出现新的插件线程组,可以满足更准确的逐步加压,插件名:jp@gc – UItimate Thred Group,
设置的线程组场景,逐步增压,前10s的时间20个用户在跑,每秒启用两个用户,10s后在启用20个用户数,相当于10-20s之间有40是个用户在跑,以此类推,达到100个用户在跑
响应时间和线程数关系图中,要求3s的响应时间内支持的多少用户数,到100用户数也没有超过3s说明100并发是可以支持的,但是从聚合报告看出,95%的响应时间超过3s,所以100用户数性能已经受到影响
评论前必须登录!
注册