三、如何估算并发用户数

方法论-1:

同时在线用户数:
平均并发数:
并发用户数峰值:

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

        (1)  计算平均的并发用户数: C = nL/T    
                 即:平均并发数=总用户数*用户在线时长/总工作时间  

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

                 即:峰值并发数=平均并发数+3*(平均并发数^1/2)
    公式(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 = 2421

估算处理能力,通常用TPCC值,即每分钟处理请求。每个服务器也把TPCC值作为指标。这与以下因素有关:
1,并发用户数?(U1)
2,用户访问模式:每分钟每个用户发出的业务请求个数,例如0.2个(N1)
3,这些业务请求中,
如果是数据库服务器,就统计查询、更新、统计占比,
如果是Web服务器,可统计,例如连接跳转、添加操作、删除操作、更新操作,查询操作除各占1/5
4,业务请求引起的事务数量
例如, 平均每次页面跳转操作产生6个事务(T1),平均每次添加操作产生8个事务(T2);平均每次删除操作产生8个事务(T3);平均每次更新操作产生14个事务(T4); 平均每次查询操作产生10个事务(T5);
5,忙时数量是平均值几倍,例如5倍
6,经验系数,例如1.8
7,服务器保留多少冗余,一般是30%
  TPC-C=U1*N1*(T1+T2+T3+ T4+ T5)/5*3*经验系数/冗余系数

方法论-2:

并发用户数

大家都知道我们的性能测试就通过工具模拟多用户对系统进行操作,对系统造成压力,来验证系统的性能(不太标准的解释)。好多人也简单的把性能测试当成并发测试。那么这个“多用户”和“同时”两个因素缺一不可。只多用户不同时,很难对系统构成压力;没有多个用户,同时的概念也就自然不存在了

并发的两种情况

一种是严格意义上的并发,即所有的用户在同一时刻做同一件事或操作,这种操作一般指做同一类型的业务。比如,所有用户同一时刻做并发登陆,同一时刻做表单提交。

另外一种并发是广义范围的并发,这种并发与前一种并发的区别是,尽管多个用户对系统发出了请求或者进行了操作,但是这些请求或都操作可以是相同的,也可以是不同的。比如,在同一时刻有用户在登录,有用户在提交表单。

从服务器的角度来看并发

前面的两种解释都是从用户业务的角度来解释并发的,因为我们平时所做的性能测试也是从用户端对业务层的操作来进行并发测试的。

如果考虑整个系统运行过程中服务器所承受的压力是这样的:在该系统的运行过程中,把整个运行过程划分为离散的时间点,在每个点上,都有一个“同时向服务端发送请求的客户数”,这个就是所谓的服务器所承受的最大并发访问数。

真正意义上的并发不存在

上面试谈了这么多并发,现在又说真正意义上的并发不存在。何解?学操作系统原理的同学都知道,CPU在一个时间点上只能干一件事儿。为什么我们可以边看电影,边打字,边语音。因为CPU很快很快,他可以处理一下电影,再处理一下打字,再处理一下语音。因为它很快,所以,它可以在多个程序之间快速瞬间的切换,给你造成的假象就是它在同时做这些事情。(现在的双核、四核的CPU另说)

那么我们的系统在接到用户的请求后也要调用CPU来完成某些处理,然后返回给用户。那么我们对系统有做并发测试是测什么呢?举个简单的例子。假如有一位神医,他的看病速度非常快,假设他的看病速度是不变的;然后有一群接待人员来接待看病的客人,有成千上万的病人来看病,接待人员要想各种办法来做好接待工作,使病人更快的看到病。比如,可以事先咨询病人得的什么病,然后将病人进行分类,比如可以扩大接待室,让更多的病人可以进到医院来看病等。

神医就是我们的CPU,接待人员就是我们的系统,病人就用户,我们做性能测试的目的就是了解接待人员哪个地方给医院看病造成了瓶颈。只来一个病人,医院的看病速度与服务很好。一下子来十万个病人各种问题就出来了。接待人员的服务态度下降,多余的人员跟本进不到医院去,医院的洗手间不够用,造成病人无法上则所而离开,这些都属于系统问题。所以,我们一般测试的目的是看医院的接待能力。

系统用户数与同时在线人数

在实际的性能测试中,经常接触到与并发用户相关的概念还有“系统用户数”与“同时在线人数”下面通过一个实例来描述他们之间的差别。

假设有一个网站,注册用户才能登录使用各种功能,如上传头像,阅读专家文章等。该系统有20万注册用户,这就是说有20万用户可以使用这个网站的所有功能,20万就是这个网站的“系统用户数”,网站有一个在线统计功能,从统计数据中可以看到,同时登录网站的人数的最高记录是2万,就是有2万人同时用浏览器打开着这个网站。2万就是“同时在线人数”

那么系统的并发用户数是多少呢?2万么?NO!这2万只表示在系统最高峰时有这么多用户登录了网站,并不表示实际服务器的承受压力。因为服务器承受压力还与具体的用户访问模式相关,在这2万用户中考察某一个时间点对用户发出请求数,可以会大大缩水。那么,该系统的服务端承受的最大并发访问数是多少呢?这个取决于业务并发用户数和业务场景,一般可以通过服务器日志的分析得到。

求并发用户数公式

在实际的性能测试工作中,测试人员一般比较关心的是业务并发用户数,也就是从业务的角度关注应该设置多少个并发数比较合理。

下面找一个典型的上班签到系统,早上8点上班,7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人,平均每个员上登录签到系统的时长为5分钟。可以用下面的方法计算。

C=1000*5/30=166.7

C表示平均并发用户数,那么对这个签到系统每秒的平均并发用户数为166

当然,在性能测试上,任何公式都不是严谨的,最重要的是对系统做出有效正确的分析。

链接:http://www.zhihu.com/question/39608108/answer/82173112

来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

猜你喜欢

转载自www.cnblogs.com/xysun/p/10904918.html