QPS、TPS、PV、UV名词介绍和计算方式（服务性能要求）

一、服务性能指标

吞吐量

全称：Throughput

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

QPS

全称：Query Per Second

每秒请求数（服务器在一秒的时间内处理了多少个请求）
简明公式：QPS = req/sec = 请求数/秒

TPS

全称： Transactions Per Second

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

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

QPS和TPS区别：

Qps 基本类似于 Tps（有些人甚至不予区分）
不同的是，对于一个页面的一次访问，形成一个 Tps；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“Qps”之中。
例如，访问一个 Index 页面会请求服务器 3 次，包括一次 html，一次 css，一次 js，那么访问这一个页面就会产生一个“TPS”，产生三个“QPS”。

PV

全称：Page View

页面访问量，即页面浏览量或点击量。
用户每一次对网站中的每个页面访问均被记录 1 次。用户对同一页面的多次刷新，访问量累计。
与 PV 相关的还有 RV，即重复访问者数量（repeat visitors）。

UV

全称：Unique Visitor

独立访客，统计1天内访问某站点的用户数。可以统计服务一天的访问日志并根据用户的唯一标识去重得到。

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

RT

全称：Response Time

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

DAU

全称：Daily Active User

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

MAU

全称：Month Active User

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

二、计算方法

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