CSS日食与太阳碰撞

 

 随笔:今天笔者给大家分享一下自己收集的关于并发量统计比较好的文章,注意是收集来的,不是笔者自写,在这里向原著致敬!

普通的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进程驻留内存啊~~~

网站并发量的计算方法

PV是什么:

PV是page view的简写。PV是指页面的访问次数,每打开或刷新一次页面,就算做一个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。因为我关心的是应用程序处理业务的能力。 

实际经验:

1、根据实际经验,采用两台常规配置的机架式服务器,配置是很常见的配置,例如一个4核CPU+4G内存+服务器SAS硬盘。

2、个人武断的认为在服务器CPU领域Intel的CPU要优于AMD的CPU,有反对的就反对吧,我都说我武断了(请看CPU性能比较),不要太相信AMD的广告,比较CPU性能简单办法就是比价格,不要比频率与核心数,价格相差不多的性能也相差不多。

3、硬盘的性能很重要,由其是数据库服务器。一般的服务器都配1.5万转的SAS硬盘,高级一点的可以配SSD固态硬盘,性能会更好。最最最最重要的指标是“随机读写性能”而不是“顺序读写性能”。(本例还是配置最常见的1.5万转的SAS硬盘吧)

4、一台服务器跑Tomcat运行j2ee程序,一台服务器跑MySql数据库,程序写的中等水平(这个真的不好量化),是论坛类型的应用(总有回帖,不太容易做缓存,也无法静态化)。

5、以上软硬件情况下,是可以承受100万PV/每天的。(已留有余量应对突然的访问高峰)

注意机房的网络带宽:

有人说以上条件我都满足了,但实际性能还是达不到目标。这时请注意你对外的网络的带宽,在国内服务器便宜但带宽很贵,很可能你在机房是与大家共享一条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带宽基本可以满足要求。

以上是假设每个页面20k字节,基本不包含图片,要是包含图片就更大了,10M带宽也不能满足要求了。你自已计算吧。

附:性能测试基本概念
--------------------------------------------------------------------------------------- 
基本概念: 
Throughput(吞吐量):按照常规理解网络吞吐量表示在单位时间内通过网卡数据量之和,其中即包括本机网卡发送出去的数据量也包括本机网卡接收到的数据量。 一个100Mb(位)的双工网卡,最大发送数据的速度是12.5M字节/s , 最大接收数据的速度是12.5M字节/s, 可以 同时 收发 数据。 
并发用户数:是同时执行操作的用户(线程数)。 
响应时间:从请求发出到收到响应花费的时间 。


QPS - Queries Per Second  每秒处理的查询数(如果是数据库,就相当于读取)
TPS - Transactions Per Second  每秒处理的事务数(如果是数据库,就相当于写入、修改)
IOPS,每秒磁盘进行的I/O操作次数

例如对某个数据库测试,分开两次测QPS与TPS。
QPS(读取)值总是高于TPS(写、改),并且有倍率关系,因为:
1、数据库对查询可能有缓存。
2、机械硬盘或SSD硬盘的读就是比写快。 

系统的平均并发用户数和并发数峰值如何估算

一、经典公式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%
原文地址:https://www.cnblogs.com/Survivalist/p/8017191.html