性能之巅-优化你的程序 [复制链接]

2019-9-20 10:20
Newpaper 阅读:401 评论:0 赞:0
Tag:??性能 优化

?


outline:关注&指标&度量,基础理论知识,工具&方法,最佳实践,参考资料



性能之巅-优化你的程序



性能优化关注:CPU、内存、磁盘IO、网络IO等四个方面。



性能之巅-优化你的程序



性能指标:吞吐率、响应时间、QPS/IOPS、TP99、资源使用率是我们经常关注的指标。



性能之巅-优化你的程序



时间度量:从cpu cycle到网络IO,自上到下,时间量级越大。



性能之巅-优化你的程序



监控、分析、优化,三部曲,以终为始,循环往复。




性能之巅-优化你的程序



优化性能,需要一些系统编程知识。



性能之巅-优化你的程序



提升处理能力、减少计算量是优化的2个根本方向。



性能之巅-优化你的程序



优化大师格雷格画的图,吊炸天,你应该很熟悉,gregg亲手实现了一些工具。



性能之巅-优化你的程序



借助工具定位性能瓶颈。gprof2dot.py可以处理多种采样输出数据

建议使用perf等非侵入式的profiling工具。



性能之巅-优化你的程序



perf不仅仅可以定位cpu瓶颈,还可以查看很多方面,比如缺页,分支预测失败,上下文切换等。



性能之巅-优化你的程序



IO瓶颈,你应该知道的知识。



性能之巅-优化你的程序



有关锁的知识,你应该知道的。



性能之巅-优化你的程序



多线程的学问很大




性能之巅-优化你的程序



内存管理的方方面面



性能之巅-优化你的程序



最佳实践,没有足够理由,你不应该违背。



性能之巅-优化你的程序



你应该懂得的。



性能之巅-优化你的程序



关于排序,你应该知道的。



性能之巅-优化你的程序


这些资料不错,你值得拥有。

如果对你有帮助,请帮忙转发,让更多朋友收益。


  • 一般性原则
  • 依据数据而不是凭空猜测
  • 忌过早优化
  • 忌过度优化
  • 深入理解业务
  • 性能优化是持久战
  • 选择合适的衡量指标、测试用例、测试环境
  • 性能优化的层次
  • 需求阶段
  • 设计阶段
  • 实现阶段
  • 一般性方法
  • 缓存
  • 并发
  • 惰性
  • 批量,合并
  • 更高效的实现
  • 缩小解空间
  • 性能优化与代码质量
  • 总结

依据数据而不是凭空猜测

这是性能优化的第一原则,当我们怀疑性能有问题的时候,应该通过测试、日志、profillig来分析出哪里有问题,有的放矢,而不是凭感觉、撞运气。一个系统有了性能问题,瓶颈有可能是CPU,有可能是内存,有可能是IO(磁盘IO,网络IO),大方向的定位可以使用top以及stat系列来定位(vmstat,iostat,netstat...),针对单个进程,可以使用pidstat来分析。

在本文中,主要讨论的是CPU相关的性能问题。按照80/20定律,绝大多数的时间都耗费在少量的代码片段里面,找出这些代码唯一可靠的办法就是profile,我所知的编程语言,都有相关的profile工具,熟练使用这些profile工具是性能优化的第一步。

忌过早优化

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

我并不十分清楚Donald Knuth说出这句名言的上下文环境,但我自己是十分认同这个观念的。在我的工作环境(以及典型的互联网应用开发)与编程模式下,追求的是快速的迭代与试错,过早的优化往往是无用功。而且,过早的优化很容易拍脑袋,优化的点往往不是真正的性能瓶颈。

忌过度优化

As performance is part of the specification of a program – a program that is unusably slow is not fit for purpose

性能优化的目标是追求合适的性价比。

在不同的阶段,我们对系统的性能会有一定的要求,比如吞吐量要达到多少多少。如果达不到这个指标,就需要去优化。如果能满足预期,那么就无需花费时间精力去优化,比如只有几十个人使用的内部系统,就不用按照十万在线的目标去优化。

而且,后面也会提到,一些优化方法是“有损”的,可能会对代码的可读性、可维护性有副作用。这个时候,就更不能过度优化。

深入理解业务

代码是服务于业务的,也许是服务于最终用户,也许是服务于其他程序员。不了解业务,很难理解系统的流程,很难找出系统设计的不足之处。后面还会提及对业务理解的重要性。

性能优化是持久战

当核心业务方向明确之后,就应该开始关注性能问题,当项目上线之后,更应该持续的进行性能检测与优化。

现在的互联网产品,不再是一锤子买卖,在上线之后还需要持续的开发,用户的涌入也会带来性能问题。因此需要自动化的检测性能问题,保持稳定的测试环境,持续的发现并解决性能问题,而不是被动地等到用户的投诉。

选择合适的衡量指标、测试用例、测试环境

正因为性能优化是一个长期的行为,所以需要固定衡量指标、测试用例、测试环境,这样才能客观反映性能的实际情况,也能展现出优化的效果。

衡量性能有很多指标,比如系统响应时间、系统吞吐量、系统并发量。不同的系统核心指标是不一样的,首先要明确本系统的核心性能诉求,固定测试用例;其次也要兼顾其他指标,不能顾此失彼。

测试环境也很重要,有一次突然发现我们的QPS高了许多,但是程序压根儿没优化,查了半天,才发现是换了一个更牛逼的物理机做测试服务器。


我来说两句
您需要登录后才可以评论 登录 | 立即注册
facelist
所有评论(0)
领先的中文移动开发者社区
18620764416
7*24全天服务
意见反馈:1294855032@qq.com

扫一扫关注我们

Powered by Discuz! X3.2? 2001-2019 Comsenz Inc.( 粤ICP备15117877号 )