主页 > Drupal > Drupal性能优化实战4则

Drupal性能优化实战4则

PDF版本

本文侧重于drupal性能优化实战,问题较为具体,如果大家想从全局上了解怎样提高drupal网站性能,请参见本站另外一篇文章:

《让猪去飞-漫谈Drupal性能优化经验贴》

这里列举几点笔者在实践中的几点总结,仅供参考。

1,给Views加缓存。

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

Views cache option

Views 缓存选项

缓存选项可以设定数据缓存和整体缓存的时间,一般来讲设置成一样即可,除非还通过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链接数都是成倍增加的。
我遇到的问题是一个网站在线用户只有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);时,这就是一个完全加载,而使得我们的缓存几乎失去意义,而当网页上存在多个这样的回调时,性能反而不如不缓存来的快。

Authcache的相关文章:
Authcache模块高级篇-动态加载内容
Drupal缓存 – Authcache模块原理详解

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讲成为问题。

以上几个场景是笔者在实际工作中遇到的与性能有关的问题,希望对大家有所帮助。


声明: 本站所有文章欢迎转载,所有文章未说明,均属于原创,转载均请注明出处。
本文有效链接: http://www.drupal001.com/2011/10/performance-optimization-in-action/
版权所有: Drupal与高性能网站架构 http://www.drupal001.com


, , , , ,

发表评论

电子邮件地址不会被公开。 必填项已用 * 标注


− 六 = 3

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

引用:0

下面所列的是引用到本博客的链接
Drupal性能优化实战4则 来自 Drupal与高性能网站架构
顶部