• 首页 首页 icon
  • 工具库 工具库 icon
    • IP查询 IP查询 icon
  • 内容库 内容库 icon
    • 快讯库 快讯库 icon
    • 精品库 精品库 icon
    • 问答库 问答库 icon
  • 更多 更多 icon
    • 服务条款 服务条款 icon

优化程序的手段

武飞扬头像
chaijowin
帮助1

学新通


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


学新通


性能优化关注: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高了许多,但是程序压根儿没优化,查了半天,才发现是换了一个更牛逼的物理机做测试服务器。

这篇好文章是转载于:学新通技术网

  • 版权申明: 本站部分内容来自互联网,仅供学习及演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,请提供相关证据及您的身份证明,我们将在收到邮件后48小时内删除。
  • 本站站名: 学新通技术网
  • 本文地址: /boutique/detail/tanhibecei
系列文章
更多 icon
同类精品
更多 icon
继续加载