Web | 扩展知识-01-一些性能测试指标概念
Contents
学习笔记：了解 Web 服务性能测试和压力测试中常见概念：QPS、TPS、RT、PV、VV、UV、吞吐率、吞吐量等等…
1. 网站的 PV、VV、UV、IP 值
1.1. PV
PV(Page View): 即页面浏览量或点击量，PV 是网站分析的一个术语，用以衡量网站用户访问的网页的数量。一般来说，PV 与来访者的数量成正比，但是 PV 并不直接决定页面的真实来访者数量，如同一个来访者通过不断刷新页面，也可以制造出非常高的 PV。 即，用户每一次对网站中的每一个网页访问均被记录一个 PV。
1.2. VV
VV(Visit View): 即访客的访问次数，用以记录所有访客一天内访问了多少次您的网站。当访客完成所有浏览，并最终关掉该网站的所有页面时便完成了一次访问，同一访客一天内可能有多次访问行为，访问次数累计。
1.3. PV 与 VV 的区别
如：你今天 10 点钟打开了百度，访问了它的三个页面；11 点钟又打开了百度，访问了它的两个页面，则 PV 数 +5，VV 数+2.
PV是指页面的浏览次数，VV是指你访问网站的次数。
1.4. UV
UV(Unique Visitor): 独立访客数，指 1 天内访问某站点的人数，以 cookie 为依据。1 天内同一访客的多次访问只计为 1 个访客
1.5. IP
IP(Internet Protocol): 即独立 IP 数，指访问过某站点的 IP 总数，以用户的 IP 地址作为统计依据。00:00-24:00内相同 IP 地址之被计算一次。
1.6. UV 与 IP 区别
如：你和你的家人用各自的账号在同一台电脑上登录新浪微博，则 IP 数 +1，UV 数 +2。由于使用的是同一台电脑，所以 IP不变，但使用的不同账号(Cookie 不同)，所以 UV+2
2. Web 性能相关
Web 性能相关要素：QPS、TPS(事务)、响应时间、并发连接数、并发用户数、吞吐量、吞吐率(RPS)等
2.1. QPS 与 TPS
2.1.1. QPS
QPS(Queries Per Second): 意思是 每秒查询率，即一台服务器每秒能够响应的查询次数，也即是最大吞吐能力，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
例如：
应用A，每个 select 查询需要 1ms, 一个 connection 的话，一直不停的执行，1S 内可执行 1000 次，也就是 1000qps。
应用B，每个 select 查询需要 100ms, 一个 connection 的话，一直不停的执行，1S 内可执行 10 次，也就是 10qps。
上面不同系统的两个qps是无法对比的，不能说哪个好哪个坏，满足业务稳定安全最重要。
2.1.2. TPS
TPS(Transactions Per Second): 也就是 事务数/秒，它是 衡量系统处理能力 的重要指标。一个 事务: 是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些数据来估计得分。
一般的，评价系统性能均以每秒钟完成的事务的数量来衡量，系统整体处理能力取决于处理能力最低模块的 TPS 值。
一个事务的完整过程如下图：
2.1.3. 如何计算 QPS 与 TPS ？
QPS(TPS) = 并发数/平均响应时间 或者 并发数 = QPS * 平均响应时间 (这里的响应时间单位：s)
举例：我们一个 HTTP 的响应时间是 20ms，在 10 个并发的情况下， QPS = 10 * (1000ms/ 20ms) = 500, 即这台服务器每秒能够响应 500 此查询。
这里有个关键点就是：QPS 一定是跟并发数联系在一起的，离开并发数谈 QPS 是没有意义的
2.1.4. QPS、TPS 和性能的关系
一个系统吞吐量通常由 QPS(TPS)、并发数两个因素决定，每套系统的这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其他消耗导致系统性能下降。来看下面一张图(图片来自 Here)：
开始，系统只有一个用户，CPU 工作肯定是不饱合的。一方面该服务器可能有多个cpu，但是只处理单个进程，另一方面，在处理一个进程中，有些阶段可能是IO阶段，这个时候会造成CPU等待，但是又没有可以被处理的其他请求进程。随着并发用户数的增加，CPU 利用率上升，QPS 相应也增加（公式为 QPS = 并发用户数/平均响应时间；随着并发用户数的增加，平均响应时间也在增加，而且平均响应时间的增加是一个指数增加曲线。而当并发数增加到很大时，每秒钟都会有很多请求需要处理，会造成进程（线程）频繁切换，反正真正用于处理请求的时间变少，每秒能够处 理的请求数反而变少，同时用户的请求等待时间也会变大，甚至超过用户的心理底线。
2.1.5. 结论
我们对单台服务器进行压测有了性能测试数据以后，我们可以根据业务上能接受最大客户响应时间对应到相应的 QPS 数，从而计算出需要的服务器的数量。举例来说，响应时间 10ms 和 1000ms 对通过浏览器的客户是没有明显体验差别的，基于 1000ms 估算服务器的数量我们的成本会降低很多。
每天 300w PV 的在单台机器上，这台机器需要多少 QPS？对于这样的问题，假设每天 80% 的访问集中在 20% 的时间里，这 20% 时间叫做峰值时间。( 3000000*0.8 ) / (3600 * 24 * 0.2 ) = 139 (QPS).
还是上面的数据，如果一台机器的 QPS 是 58，需要几台机器来支持？ 答：139 / 58 = 3
2.2. 请求时间(响应时间)
表示请求从客户端发起服务器接受，Server 处理完请求并响应结束这个过程所耗费的时间，通常叫做TTLB（Time to last byte）
请求响应过程图：
1 2 3 4 |
|￣￣￣￣￣￣￣| ____T1___ |￣￣￣￣￣￣￣| ____T2___ |￣￣￣￣￣￣￣￣| | HTTP 请求 | | Web服务处理 | | DB或其他服务 | | | ____T3___ | | ____T4___ | | ￣￣￣￣￣￣￣ ￣￣￣￣￣￣￣ ￣￣￣￣￣￣￣￣￣ |
典型的 同步方式 的HTTP请求时间为 T1+T2+T3+T4
从宏观角度来看 响应时间 = 网络响应时间 + 程序响应时间
2.2.1. 事务响应时间
事务响应时间是直接衡量系统性能的参数.
事务由一系列请求组成，事务的响应时间主要是针对用户而言，属于宏观上的概念。是为了向用户说明业务响应时间而提出的。例如:跨行取款事务的响应时间就是由一系列的请求组成的。
2.2.2. 响应时间的3/5/10原则
- 在3秒钟之内，页面给予用户响应并有所显示，可认为是“很不错的”；
- 在3~5秒钟内，页面给予用户响应并有所显示，可认为是“好的”；
- 在5~10秒钟内，页面给予用户响应并有所显示，可认为是“勉强接受的”；
- 超过10秒就让人有点不耐烦了，用户很可能不会继续等待下去；
我们在互联网企业内对web页面的响应时间要求在 1500ms 内，而HTTP的服务响应时间要求在 100ms 内。
2.3. 并发
2.3.1. 什么是并发
2.3.1.1. 狭义（严格）并发
所有用户在同一时刻做同一操作，这种操作是指同一业务类型。比如抢购某商品的时候，大量用户在同一时刻点击『立即抢购』
2.3.1.2. 广义并发
这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。
2.3.1.3. 两者区别:
可以看出，广义上的并发更接近实际情况，对于大多数系统而言只有很少的用户进行『严格意义上的并发操作』（电商抢购是典型的）
但是对 Web 性能测试而言，两种并发都要覆盖，通常先做严格意义上的并发测试，这种测试针对使用频繁的模块，严格意义的并发测试往往和『功能测试』关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。
2.3.2. 并发连接数
某个时刻，服务器所接受的请求数目，简单的讲，就是一个会话。
2.3.3. 并发用户数
并发用户数：指某一时刻同时向服务器发送请求的用户总数。
假如100个用户同时向服务器分别进行10次请求，与1个用户向服务器连续进行1000次请求。两个的效果一样么？
一个用户向服务器连续进行 1000次 请求的过程中，任何时刻服务器的网卡接受缓存区中只有来自该用户的 1 个请求，而 100 个用户同时向服务器分别进行 10次 请求的过程中，服务器网卡接收缓冲区中最多有 100 个等待处理的请求，显然这时候服务器的压力更大。
一个服务器最多支持多少并发用户数呢？ 举例说明在 Here，Here，Here
2.4. 吞吐量
吞吐量：指在一次性能测试过程中网络上传输数据量的总和。 吞吐量/传输时间 = 吞吐率
2.5. 吞吐率
吞吐率(Throughput)：指单位时间内网络上传输的数据量，也可以指单位时间内处理的客户端请求数量, 它是衡量网络性能的重要指标, 也是服务器 并发处理能力 的量化描述，单位：reqs/s。通常情况下，吞吐率用 “字节数/秒” 来衡量。当然你也可以用 “请求数/秒” 和 “页面数/秒” 来衡量。其实不管一个请求还是一个页面，它的本质都是在网络上传输的数据，那么用来表述数据的单位就是字节数。
计算公式：总请求数 / 处理完成这些请求所花费的时间，即 Request per second = Complete requests / Time taken for tests
2.6. 点击率
每秒钟用户向 WEB 服务器提交的 HTTP 请求数。
这个指标是WEB应用特有的一个指标，WEB应用是”请求-响应”模式，用户发出一次请求，服务器就要处理一次，所以点击是WEB应用能够处理的交易的最小单位。
如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大，对服务器的压力越大。
点击率只是一个性能参考指标，重要的是分析点击时产生的影响。需要注意的是，这里的点击并非指鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求.
2.7. 请求等待时间
2.7.1. 用户平均请求等待时间(Time per request)
计算公式：处理完成所有请求数所花费的时间 / （总请求数 | 并发用户数），即 Time per request = Time taken for tests /（ Complete requests / Concurrency Level）
2.7.2. 服务器平均请求等待时间(Time per request: across all concurrent requests)
计算公式：处理完成所有请求数所花费的时间 / 总请求数，即 Time taken for / testsComplete requests
可以看到，它是吞吐率的倒数。同时，它也等于用户平均请求等待时间/并发用户数，即 Time per request / Concurrency Level
3. See Also
Thanks to the authors 🙂