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

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

前后验证的结果都相符!

  • 3
    点赞
  • 56
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
回答: 在JMeter中,"samples"是指在性能测试中发送的请求的数量,而"并发用户数"是指在同一时间内同时向系统提交请求的用户数量。\[1\]并发用户数是性能测试中一个重要的指标,它可以帮助我们评估系统在高负载情况下的性能表现。在JMeter中,可以使用"Stepping Thread Group"来模拟不同的并发用户数。\[3\]该组件可以设置一个基准并发用户数,并在一定时间内逐步增加或减少并发用户数,以模拟真实的用户行为。通过观察响应时间和吞吐量等指标,我们可以评估系统在不同并发用户数下的性能表现。\[2\]因此,在JMeter中,我们可以通过调整并发用户数来模拟不同的负载情况,并观察系统的性能指标以评估系统的性能。 #### 引用[.reference_title] - *1* *2* [性能测试Jmeter之性能测试指标解析并发用户数、响应时间、吞吐量、系统性能计数器](https://blog.csdn.net/weixin_49855251/article/details/118152974)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v91^koosearch_v1,239^v3^insert_chatgpt"}} ] [.reference_item] - *3* [jmeter负载测试中如何找到最大并发用户数(实战)](https://blog.csdn.net/hanserk/article/details/123048816)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v91^koosearch_v1,239^v3^insert_chatgpt"}} ] [.reference_item] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值