网站性能优化的三重境界

这篇文章是关于网站性能优化体验的，性能优化是一个复杂的话题，牵涉的东西非常多，我只是按照我的理解列出了性能优化整个过程中需要考虑的种种因素。点到为止，包含的内容以浅显的介绍为主，如果你有见解能告知我那再好不过了。无论如何，希望阅读它的你有所收获。

 

我眼中的网站性能问题都反映了一个网站的“Availability”（中文叫做可用性，但是这个翻译也不足够达意），以往我的认识是，这个网站如果全部或者部分不可用，那是功能问题，但是如果响应慢、负载差，这才是性能问题；可是后来我逐渐意识到，性能问题涵盖的范围更广，我还没法给出一个准确定义，但是许多非业务逻辑错误引起的网站问题都可能可以算做性能问题，比如可扩展性差，比如单点故障问题。

 

 

在网站性能优化的最初阶段，也就是所谓的“第一重境界”，做局部的定位、分析和修正，考虑的仅仅是“优化”，这也是初涉性能优化问题的大多数人的认识。在问题发生以后，发现它和业务逻辑没有太大关系，就开始尝试寻找问题产生的原因并加以解决。

 

无论是网站无响应还是响应缓慢，还是响应曲线异常波动，比如，可以围绕CPU的使用问自己这样几个问题：

 

• 从CPU使用看系统是否繁忙？
• 如果系统繁忙，系统在做什么，为什么？（典型问题：HashMap不安全并发导致的死循环）
• 如果系统空闲，那么瓶颈在哪里？（典型问题：IO无响应）
• 如果响应波动，是否存在周期，周期是什么？（典型问题：连接迅速占满，每一周期批量超时断开一批）
• 如果响应波动，性能到波谷时系统在做什么？
• 是否有背景CPU使用？（即无压力下观察CPU的使用情况。典型问题：正执行的定时任务占用过多系统资源）

在这些问题中，情况虽然千变万化，简单地说，CPU的使用是核心，CPU使用率高，说明可能系统在实实在在地做事，反之，需要寻找其他瓶颈。通过结合进程、线程的快照，来初步确定问题的范围。CPU使用率低的情况居多而且容易定位，只需要寻找其他的系统瓶颈；CPU占用率偏高的问题往往比较不容易定位，虽然也有一些办法。关于具体性能问题的定位技术，这里不着过多笔墨，后续有机会详细介绍。

 

对于一个刚开始做性能优化的网站系统，下面的事情不妨都做一做，会有立竿见影的效果（如果你需要更多的建议，不妨参考这张图）：

 

• 对于使用的成熟的技术，技术社区、官方文档，往往会给出这种技术的白皮书或者优化指导，请参考。比如 Struts2的官方性能调优指南、Java6性能优化白皮书。
• 平台和虚拟机调优。对于使用平台和虚拟机的项目来说，这是必须要做的，一个JVM的参数可以对系统有显著的影响。比如Linux下连接管理的参数，JVM关于堆大小分布的参数等等。
• 前端审查。这里的审查指的是通过Page speed、YSlow等工具，以及一些业界通用的法则和经验（比如yahoo的若干条前端性能优化法则）来评估现有页面的问题。

从使用的工具上说，性能问题的定位很大程度上是面向操作系统、虚拟机系统的问题定位（这里有一些定位方法介绍）。从问题定位的时机上说，又可以分为：

 

• 截取型：截取系统某个层面的一个快照加以分析。比如一些堆栈切面和分析的工具，jstack、jmap、kill -3、MAT、Heap Analyser等。
• 监控型：监视系统变化，甚至数据流向。比如JProfiler、JConsole、JStat、BTrace等等。
• 验尸型：系统已经宕机了，但是留下了一些“罪证”，在事后来分析它们。最有名的就是JVM挂掉之后可能会留下的hs_err_pid.log，或者是生成的crash dump文件。

 

 

好，暂时说到这里，下面来看第二重境界。达到这重境界意味着已经能够跳出“事后优化”的局限了，在设计和编码的过程当中，能够正式和全面地考虑性能的因素，比如：

 

• 减少使用时间敏感的容器管理，而使用容量或数量敏感的容器管理。比如我往一个缓冲里面存放若干数据，一种设计是每10分钟flush入库一次，还有一种设计是数据到达10M大小的时候flush入库一次，通常情况下，你觉得哪个方案更可靠？
• 线程的统一管理使用。我的经验是，10次对线程创建或者线程池的使用，往往就有5次是会出问题的。
• 避免使用同步Ajax。同步Ajax会造成浏览器假死，直至响应返回。
• 分析对同步、锁的使用。即便在一些有名的开源库中，我们也不止一次发现过不合理的同步设计，N多数据，单一的全局同步块（这是一种性能设计层面上的“中心化”），结果它就成为了瓶颈，改动还不容易下手，很麻烦。

对于不成熟的团队，建议能安排有经验的程序员把关设计文档和编码中的性能问题，把常见的问题列出来参考学习。

 

达到第二重境界还有一个明显的特征就是在软件流程的前中期就开始做性能目标的论证和性能问题的验证：

 

• 性能切面分析。这指的是在系统设计初期，为了评估一个系统的性能表现，做出一个性能类似的系统原型，并对其做性能测试和评估，这时候因为性能问题而涉及到方案的变更，影响较小。据我所知，能够做到这一点的项目极少。在大多数团队中，依赖于架构师和掌握话语权的设计者依靠经验来避免性能问题带来的大的方案变更（或者，干脆摔一次跤，再进行痛苦的“重构”）。
• 性能的自动化测试验证。这一步必须伴随着Coding进行才有较大的意义，以便尽早发现性能问题。
• 设计和代码层面的评审。我的博客里面一再地强调评审的价值，不妨看看这篇和这篇。其实功能问题考虑得多、暴露得早，真正有危险的往往都是那些被忽视的非功能性问题，比如性能问题。

 

最后是第三重境界。达到这重境界的团队能够在早期规划构想阶段就将性能作为一个必备因素包含在内，这可不是随口说说的经验的估计，而是要有数据驱动的理论设计，比如做性能建模，根据市场大小、业务量、服务等级等等计算出性能的具体指标，并且在此要求下做合理的架构设计。

 

这里涉及的东西有很多，除了数据，还需要有大量的思考，对于一个网站来说，不妨问问如下的问题：

 

• 数据量会有多大，我该设计什么样的存储？一致性的要求又如何？
• 实时性要求是怎么样的？用户可以接受多少时间的数据延迟？
• 网站需要考虑到什么程度的可伸缩性？
• 哪些流程的数据处理有性能风险，数据量是什么级别的？怎么解决这个问题？
• 主要的业务时间消耗是怎样的，我需要设计怎样的业务流来满足？

所有的性能问题和其他一切非功能性问题一样，都是一定程度上的trade off，所以越优秀的设计者越需要思考，来规划这些问题的解决方案。在规划中因为性能问题而涉及到的因素有哪些，太多太多了，这里列了一些供参考。

 

要达到第三重境界还要能够预测性能问题。这就需要成熟的监控体系，监控系统的变化，尽快做出反应。

 

比如国内发生了重大事件，用户量陡增，监控系统能够及时识别出用户量监控曲线一个非常明显的跳跃过程（比如持续事件超过某个值，且曲线斜率超过某个值），发出告警，并且自动扩容来应付潜在的风险。这些，都是建立在常规的业务运营数据收集基础之上的，然后需要做数据挖掘，给出关键点。

 

再比如互联网应用“缓存为王”。对于缓存的设计，甚至很大程度上决定了应用的成败（如果你很有钱，靠大量的CDN这种非常规路线的另说，呵呵）。缓存的设计需要考虑到缓存的大小、分级、队列、命中率计算、生命周期、更新换页、数据分发、数据一致性和数据持久化等等问题，这些东西往往被很多只重视那些页面展示效果和功能的人所忽视，但如果你是优秀的设计者，你需要积累这些思考。

 

Think big。有这样一个真实的例子，我们曾经发现页面模板的OGNL性能不高（两次反射之故），遂在项目中把大部分OGNL表达式都改成了EL表达式，花了很多时间精力，性能也确实提高了，但是能提高多少呢？大概只有30%，这是一种细水长流的改进，对系统的破坏性不大，但是收效也不足以令人沾沾自喜，还失去了一些OGNL的灵活性。之后，我们换了一个思路，从大局入手，给页面划分区域，定制缓存框架，引入页面缓存能力，虽然整套方案有些复杂，但是这种架构上的进化，由于页面的生成或者部分生成直接命中了缓存文件，性能一下有了飞跃，提高了600%~800%。这就是Think big，从大处着想，见得到工程大块的结构，需要足够的视野、足够的经验和积累，可以带来显著的效果。

 

通常系统容量的设计都会要求到峰值容量以上，如果是像秒杀、抢购之类对性能要求非常高的系统，往往还存在一个问题：设计了这么大的容量，平时大部分时间业务量都比较小，这些资源浪费怎么办？（题外话：这大概也是Amazon涉足云存储和云计算的初始缘由吧）

 

同时，也要看到，性能因素也是一个网站系统发展的最大推动力，再细致的思考也难以兼容那么多未知的场景，不妨多在扩展性和兼容性上下下功夫，避免网站冷清痛苦，网站大热更痛苦。