并发计算公式

Posted 2023-04-18

参考技术A 常用并发数计算公式：N=[(n*0.8*S*P)/(T*0.2)]*R

其中：n为系统用户数；

S为每个用户发生的业务笔数（QPS）；

P为每笔业务所需要访问服务器的时间，单位为秒；

T为使用业务的时间，单位为秒；

R为调节因子，缺省值为1；

示意：

S=20（每天1000个用户发生20000笔业务）；

P=30（每笔业务需要访问服务器30秒）；

T=36000（每天工作10小时）；

R=2（缺省为1，复杂的业务系统可用2）；

计算得出的并发数为：（1000*0.8*20*30/(36000*0.2)）*2=133.33；

一、经典公式

1：一般来说，利用以下经验公式进行估算系统的平均并发用户数和峰值数据

1）平均并发用户数为 C=nL/T

2）并发用户数峰值 C'=C+3*根号C

　　C是平均并发用户数，n是 Login session的数量，L是 Login session的平均长度，T是值考察的时间长度

　　C'是并发用户数峰值

　　举例1，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志中获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时内会使用该系统。

　　那么，

　　平均并发用户数为：C=400*4/8=200

　　并发用户数峰值为：C'=200+3*根号200=243

　　举例2，某公司为其170000名员工设计了一个薪酬系统，员工可进入该系统查询自己的薪酬信息，但并不是每个人都会使用这个系统，假设只有50%的人会定期用该系统，这些人里面有70%是在每个月的最后一周使用一次该系统，且平均使用系统时间为5分钟。

　　则一个月最后一周的平均并发用户数为（朝九晚五）：

　　n=170000*0.5*0.7/5=11900

　　C=11900*5/60/8=124

　　吞吐量计算为：F=Vu*R/T 单位为个/s

　　F为事务吞吐量，Vu为虚拟用户数个数，R为每个虚拟用户发出的请求数，T为处理这些请求所花费的时间

二、通用公式2：

　　对绝大多数场景，我们用（用户总量/统计时间）*影响因子（一般为3）来进行估算并发量

　　比如，以乘坐地铁为例子，每天乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，根据8/2原则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为50000*80%/（3*60*60）=3.7，约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，假定每个人需要3秒才能进站，那实际并发应为4人/s*3s=12，当然影响因子可以根据实际情况增大！

三、根据PV计算公式：

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

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

　　246.92*3=740

四、根据TPS估计：

　　公式为C=（Think time+1）*TPS

五、根据系统用户数计算：

　　并发用户数=系统最大在线用户数的8%到12%

关于并发量的简单计算公式

普通的Web系统,关于并发量与用户数的关系计算如下:

 

1.单台服务器最高并发数2000,这是业内的大牛通过各种架构/优化/技术实现的.  我们水平没那么高, 但200并发 绝对是没问题的.

2.单个请求的处理时间, 理论上的极值为70ms(这是内网Web服务器访问数据库服务器的网络时间),  我们水平没那么高, 但也绝对可以在500ms内完成一次请求(不包括用户到Web服务器的网络时间)

3.根据以上, 单台服务器 每秒可响应 400个请求.

4.每小时响应 144W 请求.

5.每天的响应不能简单 乘以24, 因为正常系统,晚上没人用, 电子商务通常在早10,下午14点,晚上19点附近会有高峰期. 根据经验,高峰期 一小时的请求量是每天请求量的十分之一.

   即每天响应 1440W请求.

6.每个页面平均有2个请求(Ajax会导致额外的请求), 静态资源请求不计入,这个只跟网络有关,即,每天响应720W个页面

7.根据经验,在网站发生实质性业务的用户 ,平均打开100个页面(这个是往高了说的).  即 单台服务器 每天可支持 7.2W个实质交易.

8.根据经验 每天 登录用户数是交易用户数的十倍,但页面打开数极少,通常是1-10,  这个忽略.  即, 单台服务器每天 有 72W个登录用户.

9.根据经验,注册用户是每天登录用户的10倍(如果没有刷僵尸用户的话), 单台服务器可以为 720W个注册用户服务.

10.使用负载均衡后,通常负载均衡服务器 会是 2/4/8/16 这个规模 , 通常不会超过16.  即 16个负载均衡服务器 可 服务 1.15亿用户(这个至少也是京东的级别了)

 

最后: 如果用户数超过以上计算,或者业务复杂度导致无法实现200并发(如:复杂业务,几十个流程),那么 我们会根据实际项目情况 采取 其他技术手段来提高 服务器集群的响应能力

如: 缓存memcache, 更高速的数据库mongo/redis,动静分离CDN,数据库分库/分表

再比如: 部分关键节点采用Java进行处理, 这里并不是说Java就比PHP好, 但在极限速度响应上,Java的确比PHP快, Java进程驻留内存啊~~~