压力测试指标（QPS、TPS、PV、RT）

QPS（Queries Per Second）每秒查询

每秒查询数率，系统每秒能够处理的查询请求次数，即一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

有两种计算公式：

QPS = req/sec = 请求数/秒

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

TPS（Transactions Per Second）每秒事务

每秒事务数，即每秒系统能够处理的事务次数。

TPS 的过程包括：客户端请求服务端、服务端内部处理、服务端返回客户端。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

TPS与QPS区别

一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。而在这个TPS中，为了处理第一次请求可能会引发后续多次对服务端的访问才能完成这次工作，每次访问都算一个QPS。所以，一个TPS可能包含多个QPS

对于一个页面的一次访问，形成一个Tps；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“Qps”之中。如：访问一个页面会请求服务器3次，一次放，产生一个“T”，产生3个“Q”

PV（Page View）页面访问量

页面被浏览的次数，每次用户访问或者刷新页面都会被计算在内。

用户对同一页面的多次刷新，访问量累计。与 PV 相关的还有 RV，即重复访问者数量（repeat visitors）。

计算公式：

日PV=QPS*60*60*24 //即QPS乘以一天的秒数

峰值QPS=(日PV*80%)/(60*60*24*20%）//通用公式每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间

UV（Unique Visitor）独立访客访问数

统计 1 天内访问某站点的用户数(以 cookie 为依据)，一台电脑终端为一个访客。

可以理解成访问某网站的电脑的数量。网站判断来访电脑的身份是通过来访电脑的 cookies 实现的。如果更换了 IP 后但不清除 cookies，再访问相同网站，该网站的统计中 UV 数是不变的。如果用户不保存 cookies 访问、清除了 cookies 或者更换设备访问，计数会加 1。00:00-24:00 内相同的客户端多次访问只计为 1 个访客。

IP（Internet Protocol）独立 IP 数

指 1 天内多少个独立的 IP 浏览了页面，即统计不同的 IP 浏览用户数量。

同一 IP 不管访问了几个页面，独立 IP 数均为 1；不同的 IP 浏览页面，计数会加 1。IP 是基于用户广域网 IP 地址来区分不同的访问者的，所以，多个用户（多个局域网 IP）在同一个路由器（同一个广域网 IP）内上网，可能被记录为一个独立 IP 访问者。如果用户不断更换 IP，则有可能被多次统计。

RT（Response-time）响应时间

执行一个请求从开始到最后收到响应数据所花费的总体时间，即从客户端发起请求到收到服务器响应结果的时间。它的数值大小直接反应了系统的快慢。

用户平均请求等待时间（Time per requests）

计算公式：用户平局请求等待时间 = 总时间 / (总请求数 / 并发用户数)

服务器平均请求等待时间（Time per requests: across all concurrent requests）

计算公式：服务器平均等待时间 = 总时间 / 总请求数 = 用户平均请求等待时间 / 并发用户数

QPS和RT的关系？

1.对于大部分web系统，响应时间一般由CPU执行时间，线程等待时间（IO等待，sleep, wait）时间组成。QPS和RT成反比关系

2.在实际的测试环境中，QPS和RT并不是非常直接的反比关系

并发数（The number of concurrent connections）

并发请求数/连接数，是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。

计算公式：并发量 = QPS * 平均响应时间，并发请求数 = 并发用户数 * 单个用户平均请求数

并发用户数（The number of concurrent users, Concurrent Level）

指的是某个时刻同时在线的用户数。一个用户可能同时会产生多个会话，也即多个请求连接数。

RPS（Requests Per Second ）吞吐量

吞吐量是指单位时间内系统能处理的请求数量，单位是 reqs/s，体现系统处理请求的能力。

吞吐率是基于并发用户数的。这句话代表了两个含义：a、吞吐率和并发用户数相关；b、不同的并发用户数下，吞吐率一般是不同的

某个并发用户数下单位时间内能处理的最大的请求数，称之为最大吞吐率。

系统的吞吐量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个request 对CPU消耗越高，外部系统接口、IO速度越慢，系统吞吐能力越低，反之越高。系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间。

计算公式：吞吐率 =并发请求数/总请求处理时长

比如：在并发用户数为1000时，一共有5000个请求，请求了5分钟，那么每秒钟，服务器可以处理5000/5*60 = 16个请求呢。这就是服务器的吞吐率

GVM（Gross Merchandise Volume）总商品价值量

GMV = 1销售额 + 2取消订单金额 + 3拒收订单金额 + 4退货订单金额*。

GMV是流水，只要你下了订单，生成订单号，就算了GMV，而这个订单转化为平台的实际收入还会有2、3、4这些流失量。

销售额一般对应的才是实际流水

实际举例

我们通过一个实例来把上面几个概念串起来理解。如果每天 80% 的访问集中在 20% 的时间里，这 20% 时间就叫做峰值时间。

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

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

1、每天300w PV 的在单台机器上，这台机器需要多少QPS？

( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

2、如果一台机器的QPS是58，需要几台机器来支持？

139 / 58 = 3

3、服务器计算

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

最佳线程数

1、单线程QPS公式：QPS=1000ms/RT

对同一个系统而言，支持的线程数越多，QPS越高。假设一个RT是80ms,则可以很容易的计算出QPS,QPS = 1000/80 = 12.5

多线程场景，如果把服务端的线程数提升到2，那么整个系统的QPS则为 2*（1000/80） = 25, 可见QPS随着线程的增加而线性增长，那QPS上不去就加线程呗，听起来很有道理，公司也说的通，但是往往现实并非如此。

2、最佳线程数量

刚好消耗完服务器的瓶颈资源的临界线程数，公式如下

最佳线程数量=（（线程等待时间+线程cpu时间）/线程cpu时间）* cpu数量

特性：

在达到最佳线程数的时候，线程数量继续递增，则QPS不变，而响应时间变长，持续递增线程数量，则QPS开始下降。

每个系统都有其最佳线程数量，但是不同状态下，最佳线程数量是会变化的。

瓶颈资源可以是CPU,可以是内存，可以是锁资源，IO资源：超过最佳线程数-导致资源的竞争，超过最佳线程数-响应时间递增。

参考：

压测指标：https://blog.csdn.net/qq_31749835/article/details/103969076

压力测试指标：https://cloud.tencent.com/developer/news/360223

QPS，TPS，吞吐量，响应时间详解及关系：https://www.cnblogs.com/kumufengchun/p/11065413.html

QPS、TPS是什么：https://www.cnblogs.com/leadership/p/11555409.html