程序性能指标

Posted 2021-03-07 leo_wl

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了程序性能指标相关的知识，希望对你有一定的参考价值。

在开始之前必须说明，本文力图简单的描述而非学院派解释。

应用程序性能指标

一般地说，单一指标无法勾画出整体水平，我们需要综合使用响应时长、并发数、吞吐量等各种指标描述应用的响应能力。网络上对相关指标有详细描述，这里作出部分解释、补充和示例。

响应时长是指系统对请求作出响应的时间，用户对该指标有直观感受。

多数请求需要获取各种资源，当发生资源争用时，响应时长无法被压缩。

例如用户需要获取 100万条记录，不讨论内存是否够用的情况，如此多的记录被读取出来，加上网络传输的时间是请求时长的绝对开销。纵然业务再优化，请求时长也不会有更多压缩空间。

DNS 解析、脚本加载，页面渲染等不在本文讨论之列，赶兴趣请以关键字 "从输入页面地址到展示页面信息都发生了些什么" 搜索相关内容。

并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。

提升并发数能够减少排队阶段的请求数量，但是面临资源瓶颈时，情况变得不一样。

我们知道检票进站后马上需要安检，安检内容之一是使用 X 光机检查乘客行李。为了便于计算假定乘客很多且检票与安检时长一致，检票窗口已经排队，那么当有 15 台 X 光机时：

以上入站系统中并发数分别为 10、15、20，并且最后一种情况产生额外的内部队伍。随着时间流逝，排队安检的人将越来越多并最终挤爆安检大厅。在各种安检场所可以看到，维持秩序的工作人员每次只放一批乘客，就是避免出现这种情况。

在业务系统中，如果资源争用引发排队，会使内存持续上涨，最终导致应用无法响应——更多的并发数只会使应用死得更快。常用应对手段就是限流，直接抛弃掉不能处理的请求。

吞吐量是指系统在单位时间内处理请求的数量，相关词汇有QPS、TPS、RPM 等，语义和适用场景略有差异。

提问：A 系统最大支持100个并发，平均请求耗时 0.8 秒，B 系统最大支持 70 个并发，平均请求耗时 0.5 秒，哪个系统的响应能力更优？

这就引入了吞吐量的概念，A 系统每秒能够完成 100/0.8 = 125 个请求，B 系统每秒能够完成 70/0.5 = 140 个请求，事实上 B 系统更优。

服务端意义上能够支持的并发数，并不能作为响应能力的主要指标，有若干原因：

达到最大并发数的情况并不是总是发生，100 个人同时浏览页面能产生多少并发？这很复杂，用户不是每时每刻在刷新页面，浏览器支持的并发数量、相关页面发起的请求数、网络情况等随时在变化，形成的峰值也无法长时间维持；
单个请求的完成时长，与最大并发数量无直接关系；
为了使响应能力最大化，部分组件的限流手段会设置并发上限；

吞吐量 = 并发数量/响应时长

综上我们需要综合使用响应时长、并发数、吞吐量等各种指标描述应用的响应能力，而吞吐量则更加直观准确。

我们已经知道响应时长、并发数与吞吐量的关系：响应时长越短，并发数越高，吞吐量就越好，应用响应能力就越优秀。反过来来说，如果请求相当耗时，那么追求优秀的响应能力或者并发能力，等同于缘木求鱼。

在业务许可的情况下，对于形如需要从数据库获取数据的请求，以下措施是可行手段：

当无法避免巨量的资源获取时，直接拒绝相关请求也是务实高效的手段。

由前文可知，并发数既不是一个有效的性能指标，该指标也不是越大越好，设置合适的并发数量需要通过调优实现，但调优不是一件容易事。

综上，应用及其背后的所有依赖共同作用，决定了应用的响应能力。