极客视点
极客时间编辑部
极客时间编辑部
113245 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/05:14
登录|注册

性能优化“三不要”原则

讲述:初明明大小:4.79M时长:05:14
你好,欢迎收听极客视点。
每个程序员都希望自己写出高性能的代码,所以,性能优化这个话题是从来没断绝过。此前,Facebook 性能优化和容量管理高级专家庄振运在他的《性能工程高手课》中总结出了性能优化六条原则,并把它们概括为:“三要,三不要”。上一篇文章,我们分享了“三要”,本文继续来了解“三不要”原则有哪些。

1. 不要过度地反常态优化

性能优化的目标,是追求最合适的性价比最高的投入产出比,在满足要求的情况下,尽量不要做过度的优化。过度的优化会增加系统复杂度和维护成本,使得开发和测试周期变长。虽然性能上带来了一定程度的提升,但是和导致的缺点来比,孰轻孰重尚不可知,需要仔细斟酌,衡量得失。
一个建议是,根据产品的性能要求来决策
在设计产品时,我们对产品的性能会有一定的要求,比如吞吐量,或者客户响应时间要达到多少多少。如果达不到这个既定指标,就需要去优化。反之,如果能满足这些指标,那么就不必要花费太多时间精力去优化。
比如,我们要设计一个内部查询系统,预计最多只有一百个人同时在线使用的话,就完全不用按照百万在线用户的目标去过度优化。
更重要的是,多数的优化方法是并不是完美无缺的,是有缺点的,尤其是可能会对系统设计的简化性,对代码的可读性和可维护性有副作用。如果系统简化性和代码可读性更加重要,当然就更不能过度优化。

2. 不要过早的不成熟优化

要体会这一原则,我们先引用著名计算机科学家高德纳(Donald Knuth)的一段话:“现实中的最大问题是,程序员往往花太多时间,在错误的地方和错误的时间来试图提高效率和性能。过早的优化,是编程中所有邪恶和悲剧(或至少是大多数邪恶和悲剧)的根源。”
你只要稍微思考一下高德纳的话,就会发现,这句话在很多场景下都是很有道理的。
比如,在敏捷开发过程中,尤其是在面对一个全新的产品时,在业界没有先例和经验可遵循的情况下,最看重的特点是快速的迭代与试错,“尽快推出产品”是最重要的。这时,过早的优化很可能优化错地方,也就是优化的地方并非真正的性能瓶颈,因此让“优化工作”成为了无用功。而且,越早的优化就越容易造成负面影响,比如影响代码的可读性和维护性。
如果一个产品已经在业界很成熟,大家非常清楚它的生产环境特点和性能瓶颈,那么优化的重要性可以适当提高。否则的话,在没有实际数据指标的基础上,为了一点点的性能提升而进行盲目优化,的确是得不偿失的。

3. 不要表面的肤浅优化

性能优化很忌讳表面和肤浅的优化,也就是那种“头痛医头,脚痛医脚”的所谓“优化”。如果对一个程序和服务没有全局的把握,没有理解底层运行机制,任何优化方案都很难达到最好的优化效果。
比如,如果你发现一个应用程序的 CPU 使用率并不高,但是吞吐率上不去,表面的优化方式可能是增大线程池来提升 CPU 使用率。这样的简单“优化”或许当时能马上看到效果,比如吞吐率也上去了,但是如果你仔细想想,就会发现如此的表面优化非常有问题。
这样的情况下,线程池开多大最合适?需不需要根据底层硬件和上层请求的变化而对线程池的大小调优呢?如果需要,那么手工调整线程池大小就是一个典型的“头痛医头”的优化。
为什么呢?
因为部署环境不会一成不变,比如以后 CPU 升级了,核数变多了,你怎么办?再次手工去调整吗?这样做很快会让人疲于奔命,难以应付,并且很容易出错。
对这样的场景,正确的优化方式,是彻底了解线程的特性,以优化线程为主。至于线程池的大小,最好能够自动调整。千万别动不动就手工调优。如果这样手工调整的参数多了,就会做出一个有很多可调参数的复杂系统,很难用,也很难调优,很不可取。就比如我们都熟悉的 JVM 调优,有上千个可调参数,非常被人诟病。
以上就是性能优化的“三不要”原则,对现代互联网的服务和系统来说,性能问题是根本的问题。如果不知道系统的性能瓶颈,查不出性能根因,不知道如何解决,无法做合理的优化,这个服务和系统一定不会高效。
《性能工程高手课》为你梳理出性能优化和容量效率方面的核心知识、通用策略和实践经验,通过对每一领域的原则和案例的讲解,带你去掌握必需的软硬技能,让你可以系统地、有条理地根据信息进行性能问题诊断,最终获得解决问题的能力。以下是这个专栏的目录,供你参考。记得使用极客视点专属口令,享受立减优惠。
优惠口令:xingneng1
适用规则:立减 10 元(满 40 元可用)
有效期:9 月 24 日 - 10 月 1 日
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

精选留言

由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论
大纲
固定大纲
1. 不要过度地反常态优化
2. 不要过早的不成熟优化
3. 不要表面的肤浅优化
显示
设置
留言
收藏
27
沉浸
阅读
分享
手机端
快捷键
回顶部