Drupal性能优化实战4则

本文侧重于drupal性能优化实战，问题较为具体，如果大家想从全局上了解怎样提高Drupal网站性能，请参见本站另外一篇文章：
8 K8 ]  P  m" z* r
: `9 U* D! e7 ]" B  [《让猪去飞-漫谈Drupal性能优化经验贴》
5 g% d  r; `7 }- R1 Y. C& i
这里列举几点笔者在实践中的几点总结，仅供参考。

1，给Views加缓存。

" h$ U; A" V/ E4 r3 m3 r9 l% B& |5 HViews可以生成一些列表，一般这些列表都不需要实时性，所以我们可以对其使用缓存，当我们察觉到一个使用了Views的页面加载比较慢时，通过Views后台配置页面的Preview，以及Devel模板的调试信息可以看到一个Views在SQL执行阶段和渲染阶段的执行时间，我们会发现这两部分都是时间花费比较长的，但SQL执行部分的消耗我们可以通过开启Views缓存来解决，这样不仅页面加载更快，同时也可以少占一次MYSQL查询，意味着更大的数据库吞吐量。

# {* z9 M- N8 {+ F1 U9 D
- |0 {8 C1 C% f, V% t
2 J8 _& W/ |6 K, j2 |( o缓存选项可以设定数据缓存和整体缓存的时间，一般来讲设置成一样即可，除非还通过Hook在结果里加入了自定义的内容。
另外一般我们用Views大部分是在读取node表，当网站数据日益庞大，读取node表的Views会产生很多性能问题，这样开启Cache就不是可选，而是必须了。同时也可以间接说明实时性较高的网站，特别是SNS网站的实时性功能不适合使用Views。当node表过大时有可能使得Views的查询变得极慢，这时当缓存更新时执行的Views SQL语句有可能会花很长时间，甚至是执行失败，这时就应该考虑使用其他技术解决，比如Solr。
2，不要用Ad模块来部署网站广告
5 s: }0 o5 T9 s3 \/ C7 {- B9 NAd模块是一个强大的广告发布管理模块，有很灵活的广告管理方式，有很多广告内置类型以及第三方广告类型，并且和许多模块可以一起使用。单从功能上来说，Ad模块是一个不错的模块，但是当在实际的网站中使用时，会给我们带来严重的性能问题。
0 w/ b9 U" N: W( `5 ~' t经过调试，原因是Ad模块自带了统计功能包括广告的展示次数和点击次数，使用的方法和Google Analystics一样，使用一个1px的图片接收若干统计变量，但问题在于由Drupal网站自己处理这样的请求，并且这个1px的请求带来的是Drupal完整的加载流程，无论是对CPU,内存还是MYSQL链接数都是成倍增加的。我遇到的问题是一个网站在线用户只有200人的时候，网站就已经非常慢的，看表面现象就是CPU始终居高不下，内存也几乎用尽，实际上是因为每个页面都有5～8个Ad广告，这样，每一个人访问网站就相当于有5～8个人同时访问网站，导致网站请求数瞬间达到最大值，出现排队。
0 l" A5 k9 g: T0 ?  P* L+ O) @4 D最后，通过禁用Ad模块证明之前的分析是正确的，而解决方案是换成Google Ad Manager模块，这样统计部分就托管给Google了，从而解决了这一性能问题。
3，小心实现Authcache的动态回调
$ ~' x1 d, v0 p3 I& w3 E" e: Q7 V. GAuthcache是一个对针对匿名和登录用户都有效的缓存方案，并且配置灵活，可以说是缓存模块中一个比较好用的模块，但是当一个网站有大量动态实时信息时其实是不适合使用Authcache的，而当网站只有少量动态内容时，Authcache是一个不错的选择，其动态内容的实现是通过JS回调，关于JS回调，本站有另外一篇文章可以作为参考《Drupal性能优化之-将Boost模块用到极致》。
* J" H9 U. w2 L$ J7 kAuthcache的JS回调有其自己的方法，一般来说默认Authcache的回调是没有完全加载Drupal的，这样对性能的影响就不是很大。但是当不小心在一个回调里写了drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);时，这就是一个完全加载，而使得我们的缓存几乎失去意义，而当网页上存在多个这样的回调时，性能反而不如不缓存来的快。
' x" w8 b/ \$ l% Y8 h4，content_profile模块的问题
. H$ b# r- Z% k' kcontent_profile模块极大的利用了node的特性实现了对用户profile的灵活管理，具体来说就是使用了内容类型的概念来区分不同类别的profile项，每一项是一个CCK字段。管理维护以及使用都很方便。但在实际应用中就遇到了意想不到的问题。
% p  V9 Z9 s* O. q- R8 H# l笔者需要使用Views对网站数据做报表，报表要求包含多个不同内容类型的content profile，这样views就自动把相关的内容类型的表关联在一起了，理论上，一个用户在每种profile内容类型下，应该只有一个node。但由于网站在创建profile node时是脚本操作的，难免存在BUG,结果造成了有的人在某个profile内容类型里有多个node，这样关联时就会带来翻倍的结果集，也就是关联的内容类型表越多，用户拥有的多余profile node越多，结果集就翻倍增加。最严重的情况在于，由于某些代码存在BUG，导致数据库中针对匿名用户在各个内容类型表中存在大量profile node.大概是每个类型有300多个profile node.这样在Views做关联以后，导致了只匿名用户(uid=0)就带来几十亿的结果集，使得这个SQL成为慢查询，页面无法呈现。
解决方法就是编写一个脚本，不断清理各类型里错误的profile node，使得结果集成为理论值。另外就目前和同事讨论的结论来看，content_profile是个双刃剑，及时没有以上BUG，在大型网站里使用也会为网站带来性能问题，核心问题在于其在频繁操作node表。当表数据达到千万级别，性能问题开始显现时，content_profile讲成为问题。
6 X# q0 f6 c: W) g* }以上几个场景是笔者在实际工作中遇到的与性能有关的问题，希望对大家有所帮助。
1 ^5 g! y7 @+ o

声明： 本站所有文章欢迎转载，所有文章未说明，均属于原创，转载均请注明出处。 本文有效链接： http://www.drupal001.com/2011/10 ... mization-in-action/ 版权所有： Drupal与高性能网站架构 http://www.drupal001.com
7 W# i; ~' }5 }  F& I+ x