关于若干性能指标的阐述

目录

应用程序性能指标
响应时长
并发数
吞吐量
如何提高应用的响应能力
尽量地压缩响应时长
设置合理的并发数量
在开始以前必须说明，本文力图简单的描述而非学院派解释。

应用程序性能指标
通常地说，单一指标没法勾画出总体水平，咱们须要综合使用响应时长、并发数、吞吐量等各类指标描述应用的响应能力。网络上对相关指标有详细描述，这里做出部分解释、补充和示例。

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

举例：乘坐火车须要检票，需关照的乘客进站效率低，火车站会开放优先通道以应对。
提问：响应时长能够被无限压缩吗？
多数请求须要获取各类资源，当发生资源争用时，响应时长没法被压缩。

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

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

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

举例：火车站会在节假日加开更多的检票通道。
提问：增长检票通道就是提升并发数，能够无限增长检票通道吗？
提高并发数可以减小排队阶段的请求数量，可是面临资源瓶颈时，状况变得不同。

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

若是只开放 10 个检票通道，可是车站内部有 5 台 X 光机处于空置状态；
若是开放到 15 个检票通道，那么所有 X 光机都处于工做状态，无人排队安检；
若是开放到 20 个检票通道，那么额外的 5 名乘客经过检票通道后，须要再次排队安检。
以上入站系统中并发数分别为 十、1五、20，而且最后一种状况产生额外的内部队伍。随着时间流逝，排队安检的人将愈来愈多并最终挤爆安检大厅。在各类安检场所能够看到，维持秩序的工做人员每次只放一批乘客，就是避免出现这种状况。

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

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

QPS：queries per second，平均每秒请求数量；
TPS：transactions per second，平均每秒事务数量；
RPM：request per minute，平均每分钟请求数量；
提问：A 系统最大支持100个并发，平均请求耗时 0.8 秒，B 系统最大支持 70 个并发，平均请求耗时 0.5 秒，哪一个系统的响应能力更优？

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

服务端意义上可以支持的并发数，并不能做为响应能力的主要指标，有若干缘由：

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

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

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

尽量地压缩响应时长
在业务许可的状况下，对于形如须要从数据库获取数据的请求，如下措施是可行手段：

缩短前置、后置步骤；
压缩外部依赖响应时长；
确保命中数据库索引；
尝试减小获取的指标数量；
尝试减小获取的记录数量；
尝试分页屡次获取；
尝试从缓存获取并稳当处理一致性问题；
当没法避免巨量的资源获取时，直接拒绝相关请求也是务实高效的手段。

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

总结使用场景；在各类场景下针对不一样配置，设置并发参数并展开测试，描绘响应能力曲线；配置变动和应用迭代时重复进行；综上，应用及其背后的全部依赖共同做用，决定了应用的响应能力。