LR-并发用户数、TPS、PV计算公式

一、并发用户数计算公式

1.例子1

1.平均并发用户数的计算公式

       C=nL / T 
其中C是平均的并发用户数，n是平均每天访问用户数，L是一天内用户从登录到退出的平均时间（操作平均时间），T是考察时间长度（一天内多长时间有用户使用系统）

2.并发用户数峰值计算公式

       C’ ≈ C+3根号C

其中，C’指并发用户数的峰值，C即是平均并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的 

既然这2个公式我们来假设一下1000万用户可能会产生的并发情况

1.n每天访问用户数量=1000万

2.假设这个服务是用作网上银行的操作，L=一天内用户从登陆到退出的平均时间设为（5分钟），T假设每天早晨8点-12点，均有用户访问。时长16小时即960分钟。

（这个用户数量，我们就假定为平均每天访问系统的用户数，如果是总用户数量，那么则需要先算出1000万用户，每天平均有多少用户访问。）

C=10000000*5/960=52083.33/m （即52083.33每分钟）

3.并发用户峰值为

C' ≈ 52083.33+3*根号52083.33=52083.33+3*228.22=52767

例子2

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

则根据公式（1）和公式（2），可以得到：

               C = 400*4/8 = 200

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

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

二、TPS(QPS):每秒钟 request/事务 数量

 一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

        QPS（TPS）：每秒钟request/事务 数量

        并发数： 系统同时处理的request/事务数

        响应时间：  一般取平均响应时间

理解了上面三个要素的意义之后，就能推算出它们之间的关系：
QPS（TPS）= 并发数/平均响应时间    或者   并发数 = QPS*平均响应时间
        一个典型的上班签到系统，早上8点上班，7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人，平均每个员上登录签到系统的时长为5分钟。可以用下面的方法计算。
QPS = 1000/(30*60) 事务/秒
平均响应时间为 = 5*60  秒
并发数= QPS*平均响应时间 = 1000/(30*60) *(5*60)=166.7

或者

并发数=1000*5/30=166.7

平均响应时间为=5*60秒

QPS=166.7/5*60=0.55事务/秒

        一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。

首先需要了解TPS和并发用户数之间的关系：

TPS就是每秒事务数，但是事务是基于虚拟用户数的，假如1个虚拟用户在1秒内完成1笔事务，那么TPS明显就是1；如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；如果某笔业务响应时间是1s,那么1个用户在1秒内只能完成1笔事务，要想达到1000TPS，至少需要1000个用户；因此可以说1个用户可以产生1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快慢。

也就是说，在评定服务器的性能时，应该结合TPS和并发用户数，以TPS为主，并发用户数为辅来衡量系统的性能。

作者最后做了综述，他认为在性能测试时并不需要用上万的用户并发去进行测试，如果只需要保证系统处理业务时间足够快，几百个用户甚至几十个用户就可以达到目的。据他了解，很多专家做过的性能测试项目基本都没有超过5000用户并发。因此对于大型系统、业务量非常高、硬件配置足够多的情况下，5000用户并发就足够了；对于中小型系统，1000用户并发就足够了。性能测试需要一套标准化流程及测试策略，在实际测试时我们还需要考虑其它方面的问题，比如如何模拟成千上万来自不同地区用户的访问场景、如何选用合适的测试软件。

重点

1、 QPS和TPS的区别

QPS：Queries Per Second意思是“每秒查询率”，  每秒钟处理完请求的次数；注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。

TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，

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

三、PV计算公式

PV是page view的简写。PV是指页面的访问次数，每打开或刷新一次页面，就算做一个pv。 

例子1

比如一个网站，每天的PV大概1000w，根据2/8原则，我们可以认为这1000w pv的80%是在一天的9个小时内完成的（人的精力有限），那么TPS为：

  1000w*80%/(9*3600)=246.92个/s,取经验因子3，则并发量应为：

  246.92*3=740

例子2

你想建设一个能承受500万PV/每天的网站吗？ 500万PV是什么概念？服务器每秒要处理多少个请求才能应对？如果计算呢？ 

计算模型： 

每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%)) / 服务器数量 。

其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时，有80%的请求发生一天的9.6个小时当中（很适合互联网的应用，白天请求多，晚上请求少）。 

简单计算的结果：

((80%*500万)/(24小时*60分*60秒*40%))/1 = 115.7个请求/秒 

((80%*100万)/(24小时*60分*60秒*40%))/1 = 23.1个请求/秒 

 

初步结论： 

现在我们在做压力测试时，就有了标准，如果你的服务器一秒能处理115.7个请求，就可以承受500万PV/每天。如果你的服务器一秒能处理23.1个请求，就可以承受100万PV/每天。

 

留足余量：

以上请求数量是均匀的分布在白天的9.6个小时中，但实际情况并不会这么均匀的分布，会有高峰有低谷。为了应对高峰时段，应该留一些余地，最少也要x2倍，x3倍也不为过。

 

115.7个请求/秒 *2倍=231.4个请求/秒

115.7个请求/秒 *3倍=347.1个请求/秒 

23.1个请求/秒 *2倍=46.2个请求/秒

23.1个请求/秒 *3倍=69.3个请求/秒

 

 

最终结论：

如果你的服务器一秒能处理231.4--347.1个请求/秒，就可以应对平均500万PV/每天。

如果你的服务器一秒能处理46.2--69.3个请求，就可以应对平均100万PV/每天。 

 

说明：

这里说明每秒N个请求，就是QPS。因为我关心的是应用程序处理业务的能力。

 

机房的网络带宽：

对外的网络的带宽，在国内服务器便宜但带宽很贵，很可能你在机房是与大家共享一条100M的光纤，实际每个人可分到2M左右带宽。再好一点5M,再好一点双线机房10M独享。

一天总流量：每个页面20k字节*100万个页面/1024=19531M字节=19G字节，

19531M/9.6小时=2034M/小时=578K字节/s   如果请求是均匀分布的，需要5M（640K字节）带宽（5Mb=640KB 注意大小写，b是位，B是字节，差了8倍），但所有请求不可能是均匀分布的，当有高峰时5M带宽一定不够，X2倍就是10M带宽。10M带宽基本可以满足要求。

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

 

转载于:https://www.cnblogs.com/11walker/p/10599136.html