工具使用性能测试spring boot

jmeter 并发用户数,在线用户数,平均并发 峰值并发实战演示

2019-11-29  本文已影响0人  Coding测试

jmeter 并发用户数,在线用户数,平均并发 峰值并发介绍:

【记录以下两个案例】

在线用户数与并发用户数的区别和比例关系

在线用户数:用户同时在一定时间段的在线数量

并发用户数:某一时刻同时向服务器发送请求的用户数

一般而言,我们习惯以5-20的比率来推算并发用户与在线用户之间的关系。即,并发与在线的比例约为5%-20%

比如,某网站存在注册用户数为10W人,但同时在线最多1W人,但这1W个人,可能只有500人会浏览帖子,500人会进行发帖,只有这1000个人对服务器才有交易,那我们计算并发量的时候,就可以以1000为标准!

        在实际的性能测试中,经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”,下面用一个实际的例子来说明它们之间的差别。

        假设有一个OA系统,该系统有2000个使用用户——这就是说,可能使用该OA系统的用户总数是2000名,这个概念就是“系统用户数”,该系统有一个“在线统计”功能(系统用一个全局变量记数所有已登录的用户),从在线统计功能中可以得到,最高峰时有500人在线(这个500就是一般所说的“同时在线人数”),那么,系统的并发用户数是多少呢?

        根据我们对业务并发用户数的定义,这500就是整个系统使用时最大的业务并发用户数。当然,500这个数值只是表明在最高峰时刻有500个用户登录了系统,并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如,在这500个“同时使用系统”的用户中,考察某一个时间点,在这个时间上,假设其中40%的用户在较有兴致地看系统公告(注意:“看”这个动作是不会对服务端产生任何负担的),20%的用户在填写复杂的表格(对用户填写的表格来说,只有在“提交”的时刻才会向服务端发送请求,填写过程是不对服务端构成压力的),20%部分用户在发呆(也就是什么也没有做),剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下,可以说,只有20%的用户真正对服务器构成了压力。因此,从上面的例子中可以看出,服务器实际承受的压力不只取决于业务并发用户数,还取决于用户的业务场景。

       在实际的性能测试工作中,测试人员一般比较关心的是业务并发用户数,也就是从业务角度关注究竟应该设置多少个并发数比较合理,因此,在后面的讨论中,也是主要针对业务并发用户数进行讨论,而且,为了方便,直接将业务并发用户数称为并发用户数。

        (1)  计算平均的并发用户数: C = nL/T      

        (2)  并发用户数峰值: C’ ≈ C+3根号C

         公式(1)中,C是平均的并发用户数;n是login session的数量;L是login session的平均长度;T指考察的时间段长度。

        公式(2)则给出了并发用户数峰值的计算方式中,其中,C’指并发用户数的峰值,C就是公式(1)中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

实例:

        假设有一个OA系统,该系统有3000个用户,平均每天大约有400个用户要访问该系统,对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。

则根据公式(1)和公式(2),可以得到:

               C = 400*4/8 = 200

               C’≈200+3*根号200 = 242

--------------------------------------------------------------------------------------------

另一实战案例:

案例操作如下 

并发200,不限迭代次数,同时在请求下面加RPS定时器。

目的是在200线程下,将RPS逐步增加到1000/S,并持续运行一段时间。

在线程下面添加TPS,HPS,响应时间三种监听器

启动jmeter,运行一段时间之后我们观察一下监听器的数据图表。

RPS 在793/s的时候,出现拐点,请求曲线的角度开始收窄

TPS在 720/s左右开始出现剧波动,前期一直保持平稳上升,可以认为这是吞吐量的一个拐点

另外,在1:03秒的时候,也就是TPS达到907/S 的时候,事物开始出现错误。此时短暂出现百度页面打不开的情况。

1:可以认为此处就是一个性能瓶颈

2:有可能是百度对ip的访问量做了限流,防止爬虫

3:有可能是我当前环境的问题,包括带宽,内存,cpu等等资源的限制,后期都需要考虑进去

观察分析聚合报告

在性能稳定的情况下,才可以套用公式去计算出最大并发数

1:稳定状态下,最大 RPS= 793/S

2:稳定情况下,响应时间大约长期保持在160 ms

3:稳定情况下,峰值并发数大约是 793*160(并发数 = RPS * 响应时间)=126

4:稳定情况下,峰值并发=平均并发 + 3*√平均并发,所以得出平均并发大约是 96

---------------------------------------------------------------------------------------------------------------------------------------------------------------

并发数 = RPS * 响应时间

图示

结果验证:

200RPS保持1分钟,查看聚合报告

首先我们就能看出,在200RPS下,平均TPS只有172!

其次,平均并发数 = 200*0.047 = 9.4   意味着我只需要9个线程,就可以在一秒内释放200RPS的压力

可以算出每个线程每秒的请求数是 200/9.4 =21,也就是一个线程一秒内最大迭代21次

反推每个请求的响应时间 大约 是 1000/21 大约是 47ms

前后验证的结果都相符!

原文地址:https://testerhome.com/articles/20770

上一篇下一篇

猜你喜欢

热点阅读