有些性能问题是时间累积慢慢产生的，到了一定时间自然就爆炸了；而更多的性能问题是
由访问量的波动导致的，例如，活动或者公司产品用户量上升；当然也有可能是一款产品
上线后就半死不活，一直没有大访问量，所以还没有引发这颗定时炸弹。
现在假设你的系统要做一次活动，产品经理或者老板告诉你预计有几十万的用户访问量，
询问系统能否承受得住这次活动的压力。如果你不清楚自己系统的性能情况，也只能战战
兢兢地回答老板，有可能大概没问题吧。
所以，要不要做性能调优，这个问题其实很好回答。所有的系统在开发完之后，多多少少
都会有性能问题，我们首先要做的就是想办法把问题暴露出来，例如进行压力测试、模拟
可能的操作场景等等，再通过性能调优去解决这些问题。
比如，当你在用某一款 App 查询某一条信息时，需要等待十几秒钟；在抢购活动中，无
法进入活动页面等等。你看，系统响应就是体现系统性能最直接的一个参考因素。
那如果系统在线上没有出现响应问题，我们是不是就不用去做性能优化了呢？再给你讲一
个故事吧。
曾经我的前前东家系统研发部门来了一位大神，为什么叫他大神，因为在他来公司的一年
时间里，他只做了一件事情，就是把服务器的数量缩减到了原来的一半，系统的性能指标，
反而还提升了。
好的系统性能调优不仅仅可以提高系统的性能，还能为公司节省资源。这也是我们做性能
调优的最直接的目的。
什么时候开始介入调优？
解决了为什么要做性能优化的问题，那么新的问题就来了：如果需要对系统做一次全面的
性能监测和优化，我们从什么时候开始介入性能调优呢？是不是越早介入越好？
其实，在项目开发的初期，我们没有必要过于在意性能优化，这样反而会让我们疲于性能
优化，不仅不会给系统性能带来提升，还会影响到开发进度，甚至获得相反的效果，给系
统带来新的问题。
我们只需要在代码层面保证有效的编码，比如，减少磁盘 I/O 操作、降低竞争锁的使用
以及使用高效的算法等等。遇到比较复杂的业务，我们可以充分利用设计模式来优化业务
代码。例如，设计商品价格的时候，往往会有很多折扣活动、红包活动，我们可以用装饰
模式去设计这个业务。
在系统编码完成之后，我们就可以对系统进行性能测试了。这时候，产品经理一般会提供
线上预期数据，我们在提供的参考平台上进行压测，通过性能分析、统计工具来统计各项
性能指标，看是否在预期范围之内。
- 1
- 2
- 3
前往页