程序性能指标
关于若干性能指标的阐述
在开始之前必须说明，本文力图简单的描述而非学院派解释。
应用程序性能指标
一般地说，单一指标无法勾画出整体水平，我们需要综合使用响应时长、并发数、吞吐量等各种指标描述应用的响应能力。网络上对相关指标有详细描述，这里作出部分解释、补充和示例。
响应时长
响应时长是指系统对请求作出响应的时间，用户对该指标有直观感受。
- 举例：乘坐火车需要检票，需关照的乘客进站效率低，火车站会开放优先通道以应对。
- 提问：响应时长可以被无限压缩吗？
多数请求需要获取各种资源，当发生资源争用时，响应时长无法被压缩。
例如用户需要获取 100万条记录，不讨论内存是否够用的情况，如此多的记录被读取出来，加上网络传输的时间是请求时长的绝对开销。纵然业务再优化，请求时长也不会有更多压缩空间。
DNS 解析、脚本加载，页面渲染等不在本文讨论之列，赶兴趣请以关键字 "从输入页面地址到展示页面信息都发生了些什么" 搜索相关内容。
并发数
并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。
- 举例：火车站会在节假日加开更多的检票通道。
- 提问：增加检票通道就是提高并发数，可以无限增加检票通道吗？
提升并发数能够减少排队阶段的请求数量，但是面临资源瓶颈时，情况变得不一样。
我们知道检票进站后马上需要安检，安检内容之一是使用 X 光机检查乘客行李。为了便于计算假定乘客很多且检票与安检时长一致，检票窗口已经排队，那么当有 15 台 X 光机时：
- 如果只开放 10 个检票通道，但是车站内部有 5 台 X 光机处于空置状态；
- 如果开放到 15 个检票通道，那么全部 X 光机都处于工作状态，无人排队安检；
- 如果开放到 20 个检票通道，那么额外的 5 名乘客通过检票通道后，需要再次排队安检。
以上入站系统中并发数分别为 10、15、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 个人同时浏览页面能产生多少并发？这很复杂，用户不是每时每刻在刷新页面，浏览器支持的并发数量、相关页面发起的请求数、网络情况等随时在变化，形成的峰值也无法长时间维持；
- 单个请求的完成时长，与最大并发数量无直接关系；
- 为了使响应能力最大化，部分组件的限流手段会设置并发上限；
吞吐量 = 并发数量/响应时长
综上我们需要综合使用响应时长、并发数、吞吐量等各种指标描述应用的响应能力，而吞吐量则更加直观准确。
如何提升应用的响应能力
我们已经知道响应时长、并发数与吞吐量的关系：响应时长越短，并发数越高，吞吐量就越好，应用响应能力就越优秀。反过来来说，如果请求相当耗时，那么追求优秀的响应能力或者并发能力，等同于缘木求鱼。
尽可能地压缩响应时长
在业务许可的情况下，对于形如需要从数据库获取数据的请求，以下措施是可行手段：
- 缩短前置、后置步骤；
- 压缩外部依赖响应时长；
- 确保命中数据库索引；
- 尝试减少获取的指标数量；
- 尝试减少获取的记录数量；
- 尝试分页多次获取；
- 尝试从缓存获取并妥当处理一致性问题；
当无法避免巨量的资源获取时，直接拒绝相关请求也是务实高效的手段。
设置合理的并发数量
由前文可知，并发数既不是一个有效的性能指标，该指标也不是越大越好，设置合适的并发数量需要通过调优实现，但调优不是一件容易事。
- 总结使用场景；
- 在各种场景下针对不同配置，设置并发参数并展开测试，描绘响应能力曲线；
- 配置变更和应用迭代时重复进行；
综上，应用及其背后的所有依赖共同作用，决定了应用的响应能力。
在开始之前必须说明，本文力图简单的描述而非学院派解释。
应用程序性能指标
一般地说，单一指标无法勾画出整体水平，我们需要综合使用响应时长、并发数、吞吐量等各种指标描述应用的响应能力。网络上对相关指标有详细描述，这里作出部分解释、补充和示例。
响应时长
响应时长是指系统对请求作出响应的时间，用户对该指标有直观感受。
- 举例：乘坐火车需要检票，需关照的乘客进站效率低，火车站会开放优先通道以应对。
- 提问：响应时长可以被无限压缩吗？
多数请求需要获取各种资源，当发生资源争用时，响应时长无法被压缩。
例如用户需要获取 100万条记录，不讨论内存是否够用的情况，如此多的记录被读取出来，加上网络传输的时间是请求时长的绝对开销。纵然业务再优化，请求时长也不会有更多压缩空间。
DNS 解析、脚本加载，页面渲染等不在本文讨论之列，赶兴趣请以关键字 "从输入页面地址到展示页面信息都发生了些什么" 搜索相关内容。
并发数
并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。
- 举例：火车站会在节假日加开更多的检票通道。
- 提问：增加检票通道就是提高并发数，可以无限增加检票通道吗？
提升并发数能够减少排队阶段的请求数量，但是面临资源瓶颈时，情况变得不一样。
我们知道检票进站后马上需要安检，安检内容之一是使用 X 光机检查乘客行李。为了便于计算假定乘客很多且检票与安检时长一致，检票窗口已经排队，那么当有 15 台 X 光机时：
- 如果只开放 10 个检票通道，但是车站内部有 5 台 X 光机处于空置状态；
- 如果开放到 15 个检票通道，那么全部 X 光机都处于工作状态，无人排队安检；
- 如果开放到 20 个检票通道，那么额外的 5 名乘客通过检票通道后，需要再次排队安检。
以上入站系统中并发数分别为 10、15、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 个人同时浏览页面能产生多少并发？这很复杂，用户不是每时每刻在刷新页面，浏览器支持的并发数量、相关页面发起的请求数、网络情况等随时在变化，形成的峰值也无法长时间维持；
- 单个请求的完成时长，与最大并发数量无直接关系；
- 为了使响应能力最大化，部分组件的限流手段会设置并发上限；
吞吐量 = 并发数量/响应时长
综上我们需要综合使用响应时长、并发数、吞吐量等各种指标描述应用的响应能力，而吞吐量则更加直观准确。
如何提升应用的响应能力
我们已经知道响应时长、并发数与吞吐量的关系：响应时长越短，并发数越高，吞吐量就越好，应用响应能力就越优秀。反过来来说，如果请求相当耗时，那么追求优秀的响应能力或者并发能力，等同于缘木求鱼。
尽可能地压缩响应时长
在业务许可的情况下，对于形如需要从数据库获取数据的请求，以下措施是可行手段：
- 缩短前置、后置步骤；
- 压缩外部依赖响应时长；
- 确保命中数据库索引；
- 尝试减少获取的指标数量；
- 尝试减少获取的记录数量；
- 尝试分页多次获取；
- 尝试从缓存获取并妥当处理一致性问题；
当无法避免巨量的资源获取时，直接拒绝相关请求也是务实高效的手段。
设置合理的并发数量
由前文可知，并发数既不是一个有效的性能指标，该指标也不是越大越好，设置合适的并发数量需要通过调优实现，但调优不是一件容易事。
- 总结使用场景；
- 在各种场景下针对不同配置，设置并发参数并展开测试，描绘响应能力曲线；
- 配置变更和应用迭代时重复进行；
综上，应用及其背后的所有依赖共同作用，决定了应用的响应能力。