昨晚翻看收藏的一些技术文章,看到了这篇:Thinking Clearly About Performance。
这篇文章对系统性能有很深刻和本质的认识,重温了里面提到的一些观点,有很多新的感悟。
这篇文章,分享里面提到的一些观点,以及我的一些思考总结。
原文地址:http://queue.acm.org/detail.cfm?id=1854041
响应时间VS吞吐量
通常来说,响应时间和吞吐量承反比例(响应时间越长吞吐量越低)。
描述响应时间的方式
尽量用百分比的方式而非平均值来描述响应时间(用户感知到的是差异变化,而非平均)!
这也是为什么在性能测试中,P90/P99的RT比平均值更受技术人员看重的原因。
性能需求指标
性能需求指标应该是明确描述的、可量化的指标需求。
如果没有明确可量化的技术指标,性能需求就是伪需求。
性能剖析思路
找到最慢的几个任务(消耗时间最多),分析它们是否有对应关系,每个任务的时间占比,得到一个明确的描述:每个任务运行消耗了多少时间!
现在有很多工具可以帮助快速的监控分析,比如jaeger、skywalking。
阿姆达尔定律
系统对某一部件采用更快执行方式所能获得的系统性能提升程度,取决于这种执行方式被使用的频率,或所占总执行时间的比例。
性能优化应该先考虑对性能提升最大(ROI)最高的方式。
性能优化排序
优先占用资源最多或消耗时间最多的任务,但要考虑优化的成本、收益、风险(没有最好的方案,只有最合适的方案)。
性能优化原则
首先专注于业务上最需要优先修正的程序,而不是从全局调优来改善性能。
要重视全局的性能表现,但解决问题要从细节和业务最需要的环节入手。
性能拐点
响应时间和吞吐量之间的某个最优负载平衡点的资源使用率的值,称为拐点。
计算公式:响应时间/资源利用率=所得结果最小的值
在完美扩展性前提下,只要系统的平均负载超过拐点,那么系统依然会面临性能瓶颈,实际生产中的拐点比上图的拐点数值更小。拐点主要有以下几个特点:
容量规划
最后:过早的考虑优化系统性能,是一场灾难!!!