系统容量预估方法

　　　　 很多朋友，不知道该怎么去计算并发？部署多少台服务器才合适？所以，今天就来聊一聊PV和并发，还有计算web服务器数量的方法。

一，PV和并发

　　       几个概念

　　　　网站流量是指网站的访问量，用来描述访问网站的用户数量以及用户所浏览的网页数量等指标，常用的统计指标包括网站的独立用户数量、总用户数量（含重复访问者）、网页浏览数量、每个用户的页面浏览数量、用户在网站的平均停留时间等。

　　　　网站访问量的常用衡量标准：独立访客(UV) 和 综合浏览量（PV）,一般以日为单位来衡量和计算。

　　　　独立访客(UV)：指一定时间范围内相同访客多次访问网站，只计算为1个独立访客。

　　　　综合浏览量（PV）：指一定时间范围内页面浏览量或点击量，用户每次刷新即被计算一次。

　　       PV计算带宽
　　　　计算带宽大小需要关注两个指标：峰值流量和页面的平均大小。

　　　　举个例子:

    　　   假设网站的平均日PV：10w 的访问量，页面平均大小0.4 M 。

   　　　 网站带宽 = 10w / （24 *60 * 60）* 0.4M * 8 =3.7 Mbps

　　　　 具体的计算公式是：网站带宽= PV / 统计时间（换算到S）*平均页面大小（单位KB）* 8

　　　　 在实际的网站运行过程中，我们的网站必须要在峰值流量时保持正常的访问，假设，峰值流量是平均流量的5倍，按照这个计算，实际需要的带宽大约在 3.7 Mbps * 5=18.5 Mbps 。

　　　　PS：1. 字节的单位是Byte，而带宽的单位是bit，1Byte=8bit,所以转换为带宽的时候，要乘以 8。

　　　　　　  2. 在实际运行中，由于缓存、CDN、白天夜里访问量不同等原因，这个是绝对情况下的算法。

 

　　       PV与并发

 

　　　　具体的计算公式是：并发连接数 = PV / 统计时间 * 页面衍生连接次数 * http响应时间 * 因数 / web服务器数量；

　　　　页面衍生连接次数: 一个页面请求，会有好几次http连接，如外部的css, js,图片等,这个根据实际情况而定。

　　　　http响应时间: 平均一个http请求的响应时间，可以使用1秒或更少。

　　　　因数: 峰值流量 和平均流量的倍数，一般使用5 ,最好根据实际情况计算后得出。

　　       例子：

　　　　10W PV的并发连接数： (100000PV / 86400秒 * 50个派生连接数 * 1秒内响应 * 5倍峰值) / 1台Web服务器 = 289 并发连接数

　　        所以，如果我们能够测试出单机的并发连接数，和 日pv 数，那么我们同样也能估算出需要web的服务器数量。

　　        还有一套通过单机 QPS计算 pv 和 需要的web服务器数量的方法，目前一些公司采用这种计算方法，但是其实计算的原理都是差不多的。

 

　　       QPS、PV和需要部署机器数量计算公式(转)

 

　　       术语说明： 
　　　　QPS = req/sec = 请求数/秒 

　         【QPS计算PV和机器的方式】 

　　       QPS统计方式 [一般使用 http_load 进行统计] 

　　　　QPS = 总请求数 / ( 进程总数 *   请求时间 ) 

　　　　QPS: 单个进程每秒请求服务器的成功次数 

　　       单台服务器每天PV计算 

　　　　公式1：每天总PV = QPS * 3600 * 6 

　　　　公式2：每天总PV = QPS * 3600 * 8 
　　     

              服务器计算 

　　　　服务器数量 =  ( 每天总PV / 单台服务器每天总PV ) 

　　     【峰值QPS和机器计算公式】 

　　　　原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间 

　　　　公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 

　　　　机器：峰值时间每秒QPS / 单台机器的QPS   = 需要的机器 

　　　　例子：每天300w PV 的在单台机器上，这台机器需要多少QPS？ 
　　　　　　　( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS) 

　　　　例子：如果一台机器的QPS是58，需要几台机器来支持？ 

　　　　　　　139 / 58 = 3 

 

二，几个重要参数

　　　　 QPS：每秒钟处理的请求数

       　　 并发量： 系统同时处理的请求数

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

　　　　 很多人经常会把并发数和QPS 混淆，理解了上面三个要素的意义之后，就能推算出它们之间的关系：QPS = 并发量 / 平均响应时间

三，容量评估的步骤与方法

　　　　项目上线后面对大量用户的访问，服务器能抗住么？如果扛不住，需要加多少台机器？

　　　　1：预估总访问量

　　　　如何知道总访问量？对于一个运营活动的访问量评估，或者一个系统上线后PV的评估，有什么好的方法？

　　　　最简单的办法就是：询问业务方，询问运营同学，询问产品同学，看产品和运营对此次活动的流量预估。

　　　　不过，业务方对于流量的预估，应该就两个指标，pv 和 用户访问数。技术人员 需要更具这两个数据，计算其他相关指标，比如  QPS 等。具体如何计算可参照我前面一篇 pv和并发 的文章。

　　　　2：预估平均QPS

　　　　总请求数 = 总PV * 页面衍生连接数

　　　　平均QPS = 总请求数 / 总时间

　　　　比如：活动落地页1小时内的总访问量是30w pv，该落地页的衍生连接数为30  ,那么落地页的平均QPS

　　　　(30w * 30) /(60 * 60) = 2500， 

　　　　3：预估峰值QPS

　　　　系统容量规划时，不能只考虑平均QPS，而是要抗住高峰的QPS，如何评估峰值QPS呢？

　　　　这个要根据实际的业务评估，通过以往的一些营销活动的 pv 等数据进行预估。一般情况，峰值QPS大概是均值QPS的3-5倍，日均QPS为1000，于是评估出峰值QPS为5000。

 　　　　不过，有一些业务例如“秒杀业务”比较难评估业务访问量，这类业务的容量评估不在此讨论。

　　　　4：预估系统、单机极限QPS

　　　　如何预估一个业务，一个服务器单机的极限QPS呢？

　　　　这个性能指标，是服务器，最基本的指标之一，所以没有其他的办法，就是压力测试。通过压力测试，算出服务器的单机极限QPS 。

　　　　在一个业务上线前，一般都需要进行压力测试（很多创业型公司，业务迭代很快的系统可能没有这一步，那就悲剧了），以APP 推送 某营销活动为例（预计 日均QPS 1000，峰值QPS 5000），业务场景可能是这样的：

　　　　1）通过 APP 推送一个活动消息 

　　　　2）运营活动H5落地页是一个web站点

　　　　3）H5落地页由缓存cache、数据库db中的数据拼装而成

　　　　通过压力测试发现，web 服务器 单机只能抗住1200的QPS，cache和数据库db 能抗住并发压力，（一般来说，1%的流量到数据库，数据库120 QPS还是能轻松抗住的，cache的话QPS能抗住，需要评估cache的带宽，这里假设cache不是瓶颈），这样，我们就得到了web单机极限的QPS是1200。一般来说，生产系统不会跑满到极限的，这样容易影响服务器的寿命和性能，单机线上允许跑到QPS 1200 * 0.8 = 960 。

　　　　扩展说一句，通过压力测试，已经知道web层是瓶颈，则可针对web 相关的做一些调整优化，以提高web 服务器 的单机QPS 。

　　　　还有，压力测试工作中，一般是以具体业务的角度进行压力测试，关心的是某个具体业务的并发量和QPS。

　　　　5：回答最开始那两个问题　　　　　

　　　　需要的机器  = 峰值QPS / 单机极限 QPS 

　　　　好了，上述已经得到了峰值QPS是5000，单机极限QPS是1000，线上部署了3台服务器：

　　　　（1）服务器能抗住么？ -> 峰值5000，单机1000，线上3台，扛不住

　　　　（2）如果扛不住，需要加多少台机器？ -> 需要额外2台，提前预留1台更好，给3台保险

 四，各网络节点性能指标

                常用性能指标

                1、操作时延：

                Heap：1us

                Off-Heap: 10us

                Memory Mapped File: 100us

                文件顺序读写：接近ms

                Socket: >1ms

                2、MySQL读写 ：2 000RW/秒，ms级

                3、Redis ：40 000RW/秒，ms级

                4、Tomcat：3 200req/秒，13ms延迟，40线程

                5、代码执行开销：逻辑分支、对象创建、

                6、框架、软件执行开销：Spring、MyBatis、Tomcat

                7、外部依应用行开销：JDBC、Rpc、Http、Redis

                8、内部应用执行开销：锁、条件

                9、其他硬件开销：IO、带宽、CPU

 

参考：

https://www.cnblogs.com/Leo_wl/p/5851868.html

https://www.cnblogs.com/zhangweizhong/p/5772330.html

https://blog.csdn.net/daybreak1209/article/details/80499175

转载于:https://www.cnblogs.com/ratels/p/10995587.html