1、QPS:单个进程每秒请求服务器的 成功次数
每秒查询率(Query Per Second) ,每秒的响应请求数，也即是最大吞吐能力。
QPS = req/sec = 请求数/秒
QPS统计方式 [一般使用 http_load 进行统计]
QPS = 总请求数 / ( 进程总数 * 请求时间 )
QPS: 单个进程每秒请求服务器的成功次数
峰值QPS:
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
2、PV（Page View）:访问量
访问量即Page View, 即页面浏览量或点击量，用户每次刷新即被计算一次
单台服务器每天PV计算
公式1：每天总PV = QPS * 3600 * 6
公式2：每天总PV = QPS * 3600 * 8
3、UV（Unique Visitor）:独立访客
独立访客即Unique Visitor,访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次
服务器数量：
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
机器：ceil( 每天总PV / 单台服务器每天总PV )
并发数：
并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量
吐吞量：
吞吐量是指系统在单位时间内处理请求的数量
4、响应时间（RT):
响应时间是指系统对请求作出响应的时间
例子：
每天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越高
原文：https://blog.csdn.net/langduhualangdu/article/details/47055789
参考2（QPS（req/sec 每秒请求数）、PV 、RT （响应时间） 之间的关系）：https://blog.csdn.net/lzwglory/article/details/69230689
|
