秒懂QPS、TPS、PV、UV、GMV、IP、RPS

蓝队云小课堂：

QPS

Queries Per Second，每秒查询数。每秒能够响应的查询次数。

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

QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。每秒的响应请求数，也即是最大吞吐能力。

TPS

Transactions Per Second 的缩写，每秒处理的事务数目。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息作出的评估分。

TPS 的过程包括：客户端请求服务端、服务端内部处理、服务端返回客户端。

例如，访问一个 Index 页面会请求服务器 3 次，包括一次 html，一次 css，一次 js，那么访问这一个页面就会产生一个“T”，产生三个“Q”。

QPS 与 TPS 区别

QPS基本类似于TPS，但是不同的是，对于一个Web页面的一次访问，形成一个TPS（就做一件事儿，打开Web网页）；但一次Web页面请求，可能产生多次对服务器的请求（html、css、js、images、files等），服务器对这些请求，就可计入QPS之中。每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

如果是对一个接口（单场景）压测，且这个接口内部不会再去请求其它接口，那么TPS等于QPS，否则，若这个接口内部还会再去请求其它接口（下载图片、文件等服务器接口），那么 TPS不等于QPS，通常是 QPS会大于TPS

PV

page view即页面浏览量

通常是衡量一个网络新闻频道或网站甚至一条网络新闻的主要指标。

用户每一次对网站中的每个页面访问均被记录 1 次。

用户对同一页面的多次刷新，访问量累计。

根据这个特性，刷网站的 PV 就很好刷了。

与 PV 相关的还有 RV，即重复访问者数量（repeat visitors）。

UV

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

IP

Internet Protocol独立 IP 数

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

同一 IP 不管访问了几个页面，独立 IP 数均为 1；

不同的 IP 浏览页面，计数会加 1。

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

RT

Response Time 响应时间是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。

响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。

对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。

响应时间是指执行一个请求从开始到最后收到响应数据所花费的总体时间,即从客户端发起请求到收到服务器响应结果的时间

GMV

Gross Merchandise Volume 的简称。只要是订单，不管消费者是否付款、卖家是否发货、是否退货，都可放进 GMV 。

RPS

RPS 代表吞吐率，即 Requests Per Second 的缩写。吞吐率是服务器并发处理能力的量化描述，单位是 reqs/s，指的是某个并发用户数下单位时间内处理的请求数。

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

有人把 RPS 说等效于 QPS。其实可以看作同一个统计方式，只是叫法不同而已。RPS/QPS，可以使用 apche ab 工具进行测量。

QPS、PV 、RT 之间的关系

在进行系统性能压测和系统性能优化的时候，会涉及到QPS,PV,RT相关的概念， QPS,PV,RT之间的关系

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

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

QPS 是什么

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

QPS如何统计

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

根据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

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

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

最佳线程数

性能压测的情况下，起初随着用户数的增加，QPS会上升，当到了一定的阀值之后，用户数量增加QPS并不会增加，或者增加不明显，同时请求的响应时间却大幅增加，这个阀值我们认为是最佳线程数。

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

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

特性：

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

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

• 瓶颈资源可以是CPU,可以是内存，可以是锁资源，IO资源

超过最佳线程数，会导致资源的竞争；超过最佳线程数，会响应时间递增。

为什么要找最佳线程数

• 过多的线程只会造成，更多的内存开销，更多的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越高

并发数**（**Parallels）

并发数是指系统同时能处理的请求数量，一般跟CPU个数，线程数有关，这反应了系统的负载能力

并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。

吞吐量**（**Throughput）

吞吐量是指单位时间内系统能处理的请求数量，体现系统处理请求的能力，这是目前最常用的性能测试指标

吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。

对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。

并发量、QPS、RT 之间的关系：

QPS = 并发量 / 平均响应时间 （推荐）

并发量 = 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=1000ms/RT,对同一个系统而言，支持的线程数越多，QPS越高。

假设一个RT是80ms,则可以很容易的计算出QPS,QPS = 1000/80 = 12.5

多线程场景，如果把服务端的线程数提升到2，那么整个系统的QPS则为 2*（1000/80） = 25,

可见QPS随着线程的增加而线性增长，那QPS上不去就加线程呗，听起来很有道理，公司也说的通，但是往往现实并非如此。

如何提升RT（响应时间）

• 减少 IO 的响应时间，减少 IO 的调用次数

并发HTTP请求，无上下文依赖，多个连接，一个线程

HTTP连接池（长连接，keep-alive）

• 减少 CPU 的使用时间

forest 循环的例子

如何提升 QPS（每秒查询数）

• 减少 CPU 的使用时间

• 增加 CPU 的数量

• 减少同步锁

如果 CPU 不能被压到 85% 以上，并且此时的OPS已经达到了峰值，则说明另有瓶颈，接下去要重点关注内存

排查内存是否有瓶颈

判断依据，是在最佳线程数量 * 5 左右的情况下，进行压测，观察 Old 区内存增长是否正常

性能压测要关注使用了多少用户数，目前的压测方式容易遗漏内存瓶颈

总结

• Proxy 应用（耗IO）的线程越多越好，当线程达到过多时，线程本身资源的开销也会成为瓶颈，线程本身也是一个资源。

所以这类Proxy应用一般采取轻程模型，NIO解决，如 nginx

• 计算型应用（耗CPU），线程数量就是CPU的核数，如搜索索引服务器，需要做大量的计算排序，非常耗CPU资源

更多小知识，可联系蓝队云一起探讨。