QPS、TPS、PV、UV、GMV、IP、RPS的概念解释

QPS （Queries Per Second）

是每秒查询率 ,是一台服务器 每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内 所处理流量多少的衡量标准, 即每秒的响应请求数，也即是最大吞吐能力；

TPS （Transactions Per Second）

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

并发量

指系统同时能处理的请求数量，同样反应了系统的负载能力。这个数值可以分析机器1s内的访问日志数量来得到；

吞吐量（Throughput）

 是指系统在单位时间内处理请求的数量，TPS、QPS都是吞吐量的常用量化指标。

1、系统吞吐量要素

一个系统的吞吐量（承压能力）与request（请求）对cpu的消耗，外部接口，IO等等紧密关联。单个request 对cpu消耗越高，外部系统接口，IO影响速度越慢，系统吞吐能力越低，反之越高。

2、重要参数

QPS(TPS),并发数，响应时间
QPS(TPS)：每秒钟request/事务 数量
并发数：系统同时处理的request/事务数
响应时间：一般取平均响应时间

3、关系

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

PV （Page View）

页面访问量，即页面浏览量或点击量，用户每次刷新即被计算一次。可以统计服务一天的访问日志得到；

UV （Unique Visitor）

独立访客，统计1天内访问某站点的用户数。可以统计服务一天的访问日志并根据用户的唯一标识去重得到。响应时间（RT）：响应时间是指系统对请求作出响应的时间，一般取平均响应时间。可以通过Nginx、Apache之类的Web Server得到。

DAU (Daily Active User)

日活跃用户数量。常用于反映网站、互联网应用或网络游戏的运营情况。DAU通常统计一日（统计日）之内，登录或使用了某个产品的用户数（去除重复登录的用户），与UV概念相似;

MAU (Month Active User)

月活跃用户数量，指网站、app等去重后的月活跃用户数量；

IP

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

GMV

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

RPS

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

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

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

RT（Response Time）

响应时间，系统对请求作出响应的时间，一般取平均响应时间。可以通过Nginx、Apache之类的Web Server得到。

一、系统设计注意事项

1、我们在做系统设计的时候就需要考虑CPU运算，IO，外部系统响应因素造成的影响以及对系统性能的初步预估。而通常情况下，我们面对需求，我们评估出来的出来QPS，并发数之外，还有另外一个维度：日pv。通过观察系统的访问日志发现，在用户量很大的情况下，各个时间周期内的同一时间段的访问流量几乎一样。比如工作日的每天早上。只要能拿到日流量图和QPS我们就可以推算日流量。通常的技术方法：

1）、找出系统的最高TPS和日PV，这两个要素有相对比较稳定的关系（除了放假、季节性因素影响之外）

2）、通过压力测试或者经验预估，得出最高TPS，然后跟进1的关系，计算出系统最高的日吞吐量。B2B中文和淘宝面对的客户群不一样，这两个客户群的网络行为不应用，他们之间的TPS和PV关系比例也不一样。

2、软件做性能测试时需要关注哪些性能呢？

首先，开发软件的目的是为了让用户使用，我们先站在用户的角度分析一下，用户需要关注哪些性能。

对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果已用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印 象。也就是我们所说的响应时间，当相应时间较小时，用户体验是很好的，当然用户体验的响应时间包括个人主观因素和客观响应时间，在设计软件时，我们就需要 考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检 索，这时用户并不知道我们后台在做什么。用户关注的是用户操作的相应时间。其次，我们站在管理员的角度考虑需要关注的性能点。

1）、 响应时间

2）、 服务器资源使用情况是否合理

3）、 应用服务器和数据库资源使用是否合理

4）、 系统能否实现扩展

5）、 系统最多支持多少用户访问、系统最大业务处理量是多少

6）、 系统性能可能存在的瓶颈在哪里

7）、 更换那些设备可以提高性能

8）、 系统能否支持7×24小时的业务访问

再次，站在开发（设计）人员角度去考虑。

1）、 架构设计是否合理

2）、 数据库设计是否合理

3）、 代码是否存在性能方面的问题

4）、 系统中是否有不合理的内存使用方式

5）、 系统中是否存在不合理的线程同步方式

6）、 系统中是否存在不合理的资源竞争

二、计算方法

QPS
QPS = req/sec = 请求数 / 秒

案例1：接近秒杀型算法

案例的业务量要求
分析：
TPS是系统每秒钟处理的任务数量，给定业务场景，我们就需要先计算出来每秒需要系统处理多少任务，从而反推在压力测试的时候，需要给压测需要多大的TPS了。

1）、用户量
用户估算有2W左右

2）、平均访问接口数
每个用户平均请求2次接口（查询用户信息接口、查询业务接口）

3）、访问时间范围
这些用户大概率会在2分钟内会访问我们的系统

4）、用户体验
业务要保证用户2s内能打开页面

计算

• 整个系统的总请求数

计算方式：用户量 * 平均访问接口数
结果：用户(2W) * 每个用户请求数(2次)= 40000次

• 每秒要求处理的请求数

计算方式：总请求数/时间（秒）
结果： 总请求数(4w次)/(2*60s) =350（333向上取个整吧）

• 每秒实际能够处理的请求数

计算方式：每秒实际处理请求数量 =【1秒，需要切换为毫秒】/单组tps处理时间【这里是按200ms返回】
结果：每秒要求处理的请求数(350) * 200ms / 1000ms= 70
每秒实际处理请求数>每秒要求处理的请求数

TPS数量 > 每秒要求处理的请求数 * tps返回时间【按200ms计算】/1000ms

结果

最终结果就是tps>70
因此可让压力测试人员按照tps100来压接口，返回在200ms以内就满足性能要求。

当然如果实际tps50的返回时间为100ms，则按照这个粗略的公式来推算，也是能够支撑的
（350 * 100/1000=35，也就是说tps高于35，返回100ms以内也是可以的）

案例2：我们来看一个日常服务的算法

如：
1）、用户量
用户估算有100w左右

2）、平均访问接口数
每个用户平均请求3次接口

3）、访问时间范围
每天访问集中白天8小时

4）、用户体验
接口200ms返回

计算

每秒日均请求数=100w（访问量）* 3（每个访问量平均请求接口数）/8（小时）/3600（切换成秒），结果就是每秒请求100次。
每秒实际能够处理的请求数 = 100 * 200/1000

结果

tps>20

如考虑日常服务的峰值，则按4 * 日均，即每秒请求400次，则tps>80即可，因此可推荐按tps=100来做接口的压力测试。

案例总结

时间段越短，数据也越接近于瞬间并发
如果用整日的数据来计算总请求数，需要按照日流量分布来估算一个峰值数据，日常APP可考虑使用 峰值=4 * 日均【当然还是要看你具体的访问量】

如果觉得以上繁杂，你也可以参考这个结论：

• 没什么人用的服务 tps 20，返回有300ms就行了
• 十万到百万级的服务，响应能达到tps50 /200ms就可以了
• 后台服务，能达到tps 20 / 200ms即可（通常后台同时使用也没多少人）
• 秒杀类的短时间高并发……TPS100或200 在 100ms内响应 应该也能撑一段时间（具体情况还是要看业务量）

峰值 QPS
原理

每天 80% 的访问集中在 20% 的时间里，这 20% 时间叫做峰值时间公式：(总 PV 数 * 80%) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数 (QPS)

案例三

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

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

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

答:139 / 58 = 3
 

最后

以上就是幸福蜜粉为你收集整理的QPS、TPS、PV、UV、GMV、IP、RPS的概念解释的全部内容，希望文章能够帮你解决QPS、TPS、PV、UV、GMV、IP、RPS的概念解释所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。