优化Movable type的几板斧

dimlau

这篇文章写在 apple4.us 转换阵营到 wordpress 之后,真的是马后炮了——我受apple4.us团队的抬爱,以一个 movable type 重度使用者的名义参与到团队中去,却因为种种原因一直没有为 apple4.us 作出什么贡献,实在是惭愧。

不过我还是打算记录一下,因为我最近也对 movable type (简称 MT )这款我使用了很久很久的 CMS 系统有些话想说一说。

apple4.us 转换到 wordpress 是因为评论速度的缓慢,其实当然还有重建页面的缓慢等等一些原因——这是使用 moable type 的站点都会遇到的问题。既然是常见问题,6A 公司不会置之不管,每次 MT 更新都会有涉及性能提升的部分,所以现在我们可以用一些方法从一定程度上解决 MT 的性能问题啦。(无视硬件差异)

1、启用队列发布功能;

队列发布功能是 MT 早已有之的功能了,作用是每隔一段时间把一些独立的重建操作集中在一次进行,这样做得好处不言而喻——评论时不必要实时更新的页面全都放进队列,则发布评论时重建的页面只有文章页面一个而已,大大缩短了评论后的等待时间。

但是可能很多使用 MT 的站点并没有启用这项功能。我建议那些没有启用该功能的站点,立即启用。设置的方法是,打开相应模板,Template Options 模板选项发布选项设置成 Via Publish Queue。可以设置成队列发布的页面有:RSS页面、站点首页、分类归档页、月份归档页、总归档页:

然后,在主机的管理后台设置 Cron jobs ,比如设置成每15分钟重建一次上述模板:

其中 Command 栏填写的内容应该类似:

cd /home/cgi-bin; perl ./tools/run-periodic-tasks -verbose >> /home/mt.log

在设置时把 /home/cgi-bin 替换为你的MT安装路径,/home/mt.log 替换成你希望的记录文件放置路径。可能根据主机管理后台的不同会有一些差异。

2、SSI 服务器端引用和模块缓存;

MT 从4.2版本开始支持这两项功能,这使得 MT 重建速度大大提升。

如上图设置后,页面内不常变化的部分就可以用 SSI 来引用,而不必在每次重建页面时都重新生成了,自然大大缩短了重建所需时间。比如每个页面都一样的页脚部分,我们可以建立一个模块叫做 Footer ,模板选项里设置该模块支持 SSI 并且设置模块缓存,举个例子设置7天。这样,在7天之内,所有的页面重建时,页脚部分都只是通过引用而不是重复写入的形式加入页面的。

关于缓存有效时间,上面例子里我们是按照固定时间单位来设置的,MT 还提供了按照新内容来触发缓存更新。比如新评论发布后更新缓存、新文章发布后更新缓存等。

再举个例子,比如大部分 blog 侧栏都会有最新文章列表,我们把这个列表单独建立模块,设置支持 SSI ,不同的是,这次我们可以把缓存有效期设置为每次有新文章发布时更新。这样,在有新文章发布之前,所有的评论导致的页面重建都不会重建该列表,很明显会缩短程序的计算时间,从而加快评论速度。

3、模板标签和 MT 内建功能的恰当使用;

这一条解释起来很麻烦我就偷懒不具体解释了,简要地说一下就是尽可能的少用诸如 <MTIf> <MTUnless> 等等判断性标签——复杂的标签嵌套形式很自然地会影响运算所需的时间。

MT 的搜索和 Tag 功能是个资源占用大户,所以我从来都不使用 tag (除了效率原因,我也觉得其实合理的分类就可以替代 tag 的存在),搜索也用 Google 提供的自定义搜索功能。

除此之外,防 spam 也是一个提升 MT 性能的关键。之前的 Ccode-Tcode 插件,可以悄无声息地阻拦 spam,但是在 MT 升级到5系列后,该插件失效了,我也换上了官方的 TypePad AntiSpam ,这个插件比 Ccode 更省心,但是不知为何最近总是误判,有时我自己的评论都会被判为 spam,所以昨天又换上了 MT-Akismet 插件,目前暂时解决了误判问题,不知道以后怎么样。

其实用 MT 这么久,我始终觉得 MT 是一个及其强大的 CMS ,而且全静态的形式我很喜欢——有种让人踏实放心的感觉。但是评论功能一直是 MT 的软肋,我甚至有想过放弃 MT 内建的评论系统而改用第三方的 Disqus 等评论系统。但是考虑到数据放在别人那里始终还是不放心,还是不折腾啦。

关于作者:定格咖啡馆主理人,著有《开家长长久久的咖啡馆》《咖啡入门书》等。

延伸阅读

本站架设在 RamNode VPS

使用 Grav CMS 发布管理