为什么
性能优化是一件有好有坏的事情,在进行性能优化之前要问清楚自己为什么要做,提升用户体验?降低机器成本?提升稳定性?性能优化是否带来了更多的维护成本这些成本是否可以接受?
从我的个人经验来看,在大型互联网公司用户体验某种程度上是排在第一位的,为了用户体验多加一些机器、增加代码带来的维护成本很多情况下都是可以接受的。双十一大促这类的零点峰值让系统在保证用户体验的提前下面临了更大的挑战,对工程师的性能优化的能力也要求的更多。
性能优化的流程
在阿里内部性能优化并没有非常规范的流程,更多的是根据以往的经验和流程来进行。一般我们都它划分为梳理业务目标、性能压测、分析定位、性能优化、性能测试等5个步骤。
业务目标梳理
在进行性能优化之前我们要对业务的目标进行梳理,包括往年大促的流量、本次大促新增的流量、各个端的流量比例等等,用数据结合经验来预估流量以及业务的目标。
性能压测
之后再进行性能压测,毫无疑问在没有进行压测之前千万不要轻易做性能优化,我们所有的优化都要根据压测的数据来进行。关于性能压测请移步查看我的另一个篇文章《大促压测我们都在做什么》
分析定位
这往往是最难的一步,因为性能瓶颈的定位既需要好的工具同时也非常依赖于经验。
工欲善其事必先利其器,不同的场景我们要选择不同的合适工具才能达到事半功倍的效果。大名鼎鼎的性能专家Brendan Gregg在性能优化上给出一张概览图,更多内容可以看他的网站
仅仅从上面一张图我们就可以看出性能优化是一个多么复杂的过程,当我们发现一个接口有性能问题的时候是该自下向上还是自上向下亦或是从局部到整体、从整体到局部,这是一个非常依赖经验的过程。
这里给出一张我们常用的性能优化的工具图,极大的简化了上面的复杂性。
性能优化
定位性能瓶颈之后,我们就可以有针对性的进行优化,下面介绍两种常见的优化模式。当然每种瓶颈都对应着自己的优化方式,并不是唯一的。
单点优化
单点优化主要注重于单个系统、应用或者单个接口的瓶颈优化,这种优化也主要运用上图的工具进行优化,常见的手段主要有:动、静态数据分离,并行化、异步化,降低链接等等
链路优化**
链路上的优化更多的是架构上的优化,比如单应用拆分为多应用,引入微服务,单元化,分布式部署,异地多机房部署等等在系统架构上。
几点经验
1.不要过早的优化,过早优化是万恶之源。
2.优化一定要以实际的数据为准
3.虽然单点优化是基础,然后很多时候链路优化带来的效果远超于单点优化带来的效果
4.2/8原则在性能领域是适用的,这也意味着很多问题是“不值得”去优化的
5.性能优化是一个反复的过程,也是随着业务的不断发展逐步进化的。