本文侧重于 drupal性能优化实战，问题较为具体，这里列举几点笔者在实践中的几点总结，仅供参考。 1，给Views加缓存。 Views可以生成一些列表，一般这些列表都不需要实时性，所以我们可以对其使用缓存，当我们察觉到一个使用了Views的页面加载比较慢时，通过Views后台配置页面的Preview，以及Devel模板的调试信息可以看到一个Views在SQL执行阶段和渲染阶段的执行时间，我们会发现这两部分都是时间花费比较长的，但SQL执行部分的消耗我们可以通过开启Views缓存来解决，这样不仅页面加载更快，同时也可以少占一次MYSQL查询，意味着更大的数据库吞吐量。
. l/ d3 S* r& I, k$ q1 H' u ]* l1 G, T, l) w; v0 i
 Views 缓存选项
( v4 a, s. x; H; \; [9 e9 d& }1 O* K/ P+ x
缓存选项可以设定数据缓存和整体缓存的时间，一般来讲设置成一样即可，除非还通过Hook在结果里加入了自定义的内容。 另外一般我们用Views大部分是在读取node表，当网站数据日益庞大，读取node表的Views会产生很多性能问题，这样开启Cache就不是可选，而是必须了。同时也可以间接说明实时性较高的网站，特别是SNS网站的实时性功能不适合使用Views。当node表过大时有可能使得Views的查询变得极慢，这时当缓存更新时执行的Views SQL语句有可能会花很长时间，甚至是执行失败，这时就应该考虑使用其他技术解决，比如Solr。 2，不要用Ad模块来部署网站广告 Ad模块是一个强大的广告发布管理模块，有很灵活的广告管理方式，有很多广告内置类型以及第三方广告类型，并且和许多模块可以一起使用。单从功能上来说，Ad模块是一个不错的模块，但是当在实际的网站中使用时，会给我们带来严重的性能问题。 经过调试，原因是Ad模块自带了统计功能包括广告的展示次数和点击次数，使用的方法和Google Analystics一样，使用一个1px的图片接收若干统计变量，但问题在于由Drupal网站自己处理这样的请求，并且这个1px的请求带来的是Drupal完整的加载流程，无论是对CPU,内存还是MYSQL链接数都是成倍增加的。
8 x0 Z a$ }, g; _! [我遇到的问题是一个网站在线用户只有200人的时候，网站就已经非常慢的，看表面现象就是CPU始终居高不下，内存也几乎用尽，实际上是因为每个页面都有5～8个Ad广告，这样，每一个人访问网站就相当于有5～8个人同时访问网站，导致网站请求数瞬间达到最大值，出现排队。 最后，通过禁用Ad模块证明之前的分析是正确的，而解决方案是换成Google Ad Manager模块，这样统计部分就托管给Google了，从而解决了这一性能问题。 3，小心实现Authcache的动态回调 Authcache是一个对针对匿名和登录用户都有效的缓存方案，并且配置灵活，可以说是缓存模块中一个比较好用的模块，但是当一个网站有大量动态实时信息时其实是不适合使用Authcache的，而当网站只有少量动态内容时，Authcache是一个不错的选择，其动态内容的实现是通过JS回调，关于JS回调，本站有另外一篇文章可以作为参考《 Drupal性能优化之-将Boost模块用到极致》。 Authcache的JS回调有其自己的方法，一般来说默认Authcache的回调是没有完全加载Drupal的，这样对性能的影响就不是很大。但是当不小心在一个回调里写了drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);时，这就是一个完全加载，而使得我们的缓存几乎失去意义，而当网页上存在多个这样的回调时，性能反而不如不缓存来的快。 4，content_profile模块的问题 content_profile模块极大的利用了node的特性实现了对用户profile的灵活管理，具体来说就是使用了内容类型的概念来区分不同类别的profile项，每一项是一个CCK字段。管理维护以及使用都很方便。但在实际应用中就遇到了意想不到的问题。 笔者需要使用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讲成为问题。 以上几个场景是笔者在实际工作中遇到的与性能有关的问题，希望对大家有所帮助。
8 M. F/ P7 ?* s3 W2 f
4 @8 G, N- K5 a; m
+ n3 n- f! _2 E7 J( O4 o% d# p% a | 
发表于 2-7-2012 03:07