昨晚翻看收藏的一些技术文章，看到了这篇：Thinking Clearly About Performance。
这篇文章对系统性能有很深刻和本质的认识，重温了里面提到的一些观点，有很多新的感悟。
这篇文章，分享里面提到的一些观点，以及我的一些思考总结。
原文地址：http://queue.acm.org/detail.cfm?id=1854041
友情提醒，文末有福利哦！
响应时间VS吞吐量
通常来说，响应时间和吞吐量承反比例（响应时间越长吞吐量越低）。
- 性能优化是需要多维度去衡量和优化的领域；
- 响应时间和吞吐量并没有直接的关系（但是有间接关系）；
- 一般来说，性能优化的目标是：在尽量保持和降低响应时间的情况下，不断提高吞吐量，提高流量高峰时间的系统服务可用性（大多数情况，而非全部）；
- 响应时间、吞吐量、可用性等因素有时候存在矛盾，需要综合考虑业务情况、系统模块的依赖关系、处理方式（单线程/多线程/负载均衡）等因素，做到合理取舍；
描述响应时间的方式
尽量用百分比的方式而非平均值来描述响应时间（用户感知到的是差异变化，而非平均）！
这也是为什么在性能测试中，P90/P99的RT比平均值更受技术人员看重的原因。
性能需求指标
性能需求指标应该是明确描述的、可量化的指标需求。
如果没有明确可量化的技术指标，性能需求就是伪需求。
性能剖析思路
找到最慢的几个任务（消耗时间最多），分析它们是否有对应关系，每个任务的时间占比，得到一个明确的描述：每个任务运行消耗了多少时间！
现在有很多工具可以帮助快速的监控分析，比如jaeger、skywalking。
阿姆达尔定律
系统对某一部件采用更快执行方式所能获得的系统性能提升程度，取决于这种执行方式被使用的频率，或所占总执行时间的比例。
性能优化应该先考虑对性能提升最大（ROI）最高的方式。
性能优化排序
优先占用资源最多或消耗时间最多的任务，但要考虑优化的成本、收益、风险（没有最好的方案，只有最合适的方案）。
性能优化原则
首先专注于业务上最需要优先修正的程序，而不是从全局调优来改善性能。
要重视全局的性能表现，但解决问题要从细节和业务最需要的环节入手。
性能拐点
响应时间和吞吐量之间的某个最优负载平衡点的资源使用率的值，称为拐点。
计算公式：响应时间/资源利用率=所得结果最小的值
在完美扩展性前提下，只要系统的平均负载超过拐点，那么系统依然会面临性能瓶颈，实际生产中的拐点比上图的拐点数值更小。拐点主要有以下几个特点：
- 系统中的每一项资源都存在拐点；
- 系统的拐点都≤上图中给出的值，系统的扩展完美型越差，拐点越小；
- 对于请求随机到达的系统，如果资源负载持续超过拐点，那么将遇到性能瓶颈；
容量规划
- 如果系统中某项资源超过它的拐点，就会遇到性能瓶颈；
- 保持资源利用率低于拐点，系统表现则基本不会低于我们的期望值；
- 遇到容量瓶颈，解决方式是：重新配置负载分配（减少负载OR增加容量）；
- 某项资源的容量就是高峰期可以轻松运行任务而资源使用率不会超过拐点的值；
最后：过早的考虑优化系统性能，是一场灾难！！！
