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

前后验证的结果都相符！

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你

关注我的微信公众号【伤心的辣条】免费获取~

送上一句话：

世界的模样取决于你凝视它的目光，自己的价值取决于你的追求和心态，一切美好的愿望，不在等待中拥有，而是在奋斗中争取。

我的学习交流群：902061117 群里有技术大牛一起交流分享~

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！

好文推荐：

转行面试，跳槽面试，软件测试人员都必须知道的这几种面试技巧！

测试岗反复跳槽，跳着跳着就跳没了…

软件测试人员该学习 Python 的七个理由

App公共测试用例梳理

面试经：一线城市搬砖！又面软件测试岗，5000就知足了…

35岁之后软件测试工程师靠什么养家？我能继续做测试！