概念

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

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

• 独立访客(UV)：指一定时间范围内相同访客多次访问网站，只计算为1个独立访客。
• 综合浏览量（PV）：指一定时间范围内页面浏览量或点击量，用户每次刷新即被计算一次。
• tps是每秒内的事务数，比如执行了dml操作，那么相应的tps会增加。
• qps是指每秒内查询次数，比如执行了select操作，相应的qps会增加。
• Throughput（吞吐量）：按照常规理解网络吞吐量表示在单位时间内通过网卡数据量之和，其中即包括本机网卡发送出去的数据量也包括本机网卡接收到的数据量。 一个100Mb(位)的双工网卡，最大发送数据的速度是12.5M字节/s ， 最大接收数据的速度是12.5M字节/s， 可以 同时 收发 数据。
• 并发用户数：是同时执行操作的用户(线程数)。
• 响应时间：从请求发出到收到响应花费的时间 。
• IOPS，每秒磁盘进行的I/O操作次数

根据PV计算带宽

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

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

示例：

假设网站的平均日PV：10w 的访问量，页面平均大小0.4 M 。
网站带宽 = 10w / （24 *60 * 60）* 0.4M * 8 =3.7 Mbps

注意：

• 字节的单位是Byte，而带宽的单位是bit，1Byte=8bit,所以转换为带宽的时候，要乘以 8。
• 在实际运行中，由于缓存、CDN、白天夜里访问量不同等原因，这个是绝对情况下的算法。例如如果应用基本都是在白天被访问，统计时间就需要按12小时或8小时来计算
• 带宽都是偶数和整数，所以上面示例需要准备的带宽应该是6M

峰值

在实际的网站运行过程中，我们的网站必须要在峰值流量时保持正常的访问，假设，峰值流量是平均流量的5倍（根据实际情况估算），按照这个计算，实际需要的带宽大约在 3.7 Mbps * 5=18.5 Mbps 。向上去偶数后为20M

根据PV计算并发

计算公式

并发连接数 = PV / 统计时间 * 页面衍生连接次数 * http响应时间 * 因数 / web服务器数量；

说明：

• 页面衍生连接次数: 一个页面请求，会有好几次http连接，如外部的css, js,图片等,这个根据实际情况而定。
• http响应时间: 平均一个http请求的响应时间，可以使用1秒或更少。
• 因数: 峰值流量 和平均流量的倍数，一般使用5 ,最好根据实际情况计算后得出。
• 统计时间：由于白天夜里访问量不同等原因，需要适当调整统计时间

示例， 10PV的并发连接数：

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

根据PV计算服务器数量

计算公式和计算并发类似

并发连接数 = PV / 统计时间 * 页面衍生连接次数 * http响应时间 * 因数 / 单机的并发连接数；

根据QPS计算PV和服务器数量

术语

QPS = req/sec = 请求数/秒 ，单个进程每秒请求服务器的成功次数

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

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

PV的计算

每天总PV = QPS * 统计时间(秒) * 服务器数量

服务器计算

服务器数量 = ( 每天总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并不会增加，或者增加不明显，同时请求的响应时间却大幅增加。这个阀值我们认为是最佳线程数。 为什么要找最佳线程数

• 过多的线程只会造成，更多的内存开销，更多的CPU开销，但是对提升QPS确毫无帮助
• 找到最佳线程数后通过简单的设置，可以让web系统更加稳定，得到最高，最稳定的QPS输出

最佳线程数的获取：

• 通过用户慢慢递增来进行性能压测，观察QPS，响应时间
• 根据公式计算:服务器端最佳线程数量=((线程等待时间+线程cpu时间)/线程cpu时间) * cpu数量
• 单用户压测，查看CPU的消耗，然后直接乘以百分比，再进行压测，一般这个值的附近应该就是最佳线程数量

影响最佳线程数的主要因素：

• IO

IO开销较多的应用其CPU线程等待时间会比较长，所以线程数量可以开的多一些，相反则线程数量要少一些，其实有两种极端，纯IO的应用，比如proxy，则线程数量可以开到非常大（实在太大了则需要考虑线程切换的开销），这种应用基本上后端（比如这个proxy是代理搜索的）的QPS能有多少，proxy就有多少。

• CPU

对于耗CPU的计算，这种情况一般来讲只能开到CPU个数的线程数量。但是并不是说这种应用的QPS就不高，往往这种应用的QPS可以很高，因为耗CPU计算的应用，往往处理单次请求的时间会很短。

QPS和线程数的关系

• 在最佳线程数量之前，QPS和线程是互相递增的关系，线程数量到了最佳线程之后，QPS持平，不在上升，甚至略有下降，同时响应时间持续上升。
• 同一个系统而言，最佳线程数越多，QPS越高

参考资料

http://www.58maisui.com/2016/08/18/107/ https://my.oschina.net/moooofly/blog/178750