压测性能指标之间的关系

下面是性能测试的主要概念和计算公式，记录下：

一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。

单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

QPS是什么？

QPS：单个进程每秒请求服务器的 成功次数 
QPS = req/sec = 并发数/平均响应时间

 QPS如何统计？

QPS统计方式 [一般使用 http_load 进行统计] 
QPS = 总请求数 / ( 进程总数 * 请求时间 )

 一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。

 

PV即Page View，网站浏览量
指页面的浏览次数，用于衡量网站用户访问的网页数量。用户每次打开一个页面便记录1次PV，多次打开同一页面则浏览量累计。一般来说，PV与来访者的数量成正比，但是PV并不直接决定页面的真实来访者数量，如同一个来访者通过不断的刷新页面，也可以制造出非常高的PV。具体的说，PV值就是所有访问者在24小时（0点到24点）内看了某个网站多少个页面或某个网页多少次。PV是指页面刷新的次数，每一次页面刷新，就算做一次PV流量。

度量方法就是从浏览器发出一个对网络服务器的请（Request），网络服务器接到这个请求后，会将该请求对应的一个网页（Page）发送给浏览器，从而产生了一个PV。那么在这里只要是这个请求发送给了浏览器，无论这个页面是否完全打开（下载完成），那么都是应当计为1个PV。

 根据QPS推算PV：

单台服务器每天PV计算: 
公式1：每天总PV = QPS * 3600 * 6 
公式2：每天总PV = QPS * 3600 * 8

 根据QPS,PV推算服务器数量

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

峰值QPS和机器计算公式： 
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间 
峰值时间每秒请求数(QPS)： ( 总PV数 * 80% ) / ( 每天秒数 * 20% ) 
峰值机器数量： 峰值时间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越高