February 25, 2009
简评 WordPress 缓存插件：Hyper Cache
由于流量太大，三表的博客打起了摆子，其实早些时候我就留意过他的博客，没有使用任何缓存手段还扛得住那么多人踩觉得有点不可思议，结果是没赶上摆子发作罢了。今天再去看的时候，他已经安装上了 Hyper Cache，于是我得赶紧了解一下，否则跟人讲起来连 Hyper Cache 都不知道，还好意思说自己玩几年 WordPress？
稍微介绍一下 Hyper Cache，从功能上来说，Hyper Cache 跟 WP Cache、WP Super Cache、cos-html-cache 等插件一样都是 WordPress 的缓存插件，WordPress 本身动态生成页面的特性导致其性能一直为人诟病，表现为速度慢、服务器负载重等，于是大家想出一系列的办法来修正这个问题，我见过的思路有以下几种：
- 缓存数据库查询，减轻 SQL 查询负担
- 缓存页面，减轻 PHP 解释负担
- 生成真正的静态化页面，把 SQL 查询减少至 0，PHP 解释减少至 0 或接近 0
上面分得不一定严谨准确，我只是粗略划分一下（另外，本篇文章可能含有错误，发现并指正有奖）。
第一种思路的代表是 WP Cache，这是我用过最早的缓存插件，效果非常一般。我觉得这个思路本身就是矛盾的，缓存更新比较快的数据，打个比方说评论吧，缓存了可能会导致查询最新评论结果不准确，不缓存吧查询频率还比较高。貌似 WP Cache 有后续版本？不好意思没关注过。
第二种思路的代表是 WP Super Cache，不过我觉得这么说可能不太准确，它应该也结合了第一种思路，貌似大家对 WP Super Cache 评价还比较高，但是我的看法是：不过如此。
第三种思路的代表是 cos-html-cache，在看过 Hyper Cache 的源代码之后，我把它也归进这第三种思路中，但这二者又有差异。cos-html-cache 的机制是生成真正静态的 HTML 文件，所以这个插件也要求把 WordPress 的永久链接格式改为 .html 结尾，它的优势非常明显：缓存机制彻底绕过了 WordPress，完全没有 PHP 和 SQL 消耗。在发生第一次访问请求时，生成页面缓存，缓存生成之后，所有访问请求到的页面都是一个真正的 HTML 网页，显然优化程度已经达到了极限。
与之相比，Hyper Cache 并没有完全脱离 WordPress，虽然它也会生成静态的页面（不是 HTML 网页，而是序列化后的二进制数据），但为了保证插件适用范围更广，Hyper Cache 仍然依赖于 WordPress 的插件机制，当有访问请求时，Hyper Cache 首先会检查是否生成了缓存，如果缓存存在，把二进制缓存数据反序列化并返回，否则生成缓存。（包括生成方式在内，Hyper Cache 更新缓存的方式跟 cos-html-cache 也无二致，都会在有新评论、有新日志产生的时候更新相应的部分缓存。）
由此可见，有人说“Hyper Cache 轻松打败 WP Super Cache”是有道理的，但与 cos-html-cache 的优化效果相比，还是存在一定的差距。不过 Hyper Cache 仍然称得上是一款优秀的 WordPress 缓存插件，良好的缓存性能、对永久链接格式没有苛刻的要求、支持 gzip 压缩另外还有易用的配置界面（实话说我只看过这个页面的源代码），都足以让 Hyper Cache 代替 WP Super Cache 成为非 geek WordPress 用户的选择。
1) Super Cache是生成静态页面的，只需要Apache或者Nginx的rewrite即可，效率很不错了。
2) Hyper Cache 轻松打败 WP Super Cache ? 有测试报告么…
@Aw Guo
1) Super Cache 虽然也缓存了页面，但是跟 cos-html-cache 和 Hyper Cache 相比，“静态”的程度不高，是一种更加“动态”的静态，而 cos-html-cache 和 Hyper Cache 的静态程度要彻底地多，是丝毫没有折扣的静态。正是因为这一点，Super Cache 的效果比不上后两者。
2) 没有测试报告，我仅是从理论上证明这一点。
谢谢 aw 前来指教！
@Andor 你这是褒呢还是贬呢？
我喜欢cos-html-cache
试试Hyper Cache～
@sansky Me too.
之前我使用的是Hyper Cache，发现启用之后博客就不记录cookie了，也就是回访的留言者要再次输入个人信息。
当换到Super Cache后，这个问题解决了。
这是几个月之前的事，不保证现在Hyper Cache还出现一样的情况。不过Hyper Cache的插件文件似乎比Super Cache要少一些，不知这是否会提高运行效率？
@Jason Ng
是的，这个现象正是因为彻底静态化导致的——因为 WordPress 验证 cookie 的代码是用 PHP 写的，静态化之后已经没有了 WordPress 的介入，所以 cookie 会失效。
解决的办法就是使用 JavaScript 来验证 cookie，以及加入动态的功能——我的博客就是完全静态化的，“我的留言”、“订阅统计”还有 cookie 验证都是通过 JavaScript 完成的。
同时这一点也可以证明 Super Cache 不是完全静态化的，它的静态化有所保留，所以效率高不到哪里去，甚至在某些情况下可能由于频繁建立缓存而起到反作用——这种情况我是遇到过的。
Hyper Cache 效率比 Super Cache 高的主要原因是缓存机制上的优势，跟文件数量可能有一点关系，但我想应该不是主要原因。
@冰仔：你猜是褒还是贬
原来 twitter 那个头像是你啊，我以为是谁呢 
@Andor 哈哈，看来大家都对这个头像有兴趣啊。
只可惜cos-html只管post页面。其他的都给放行了。再搭配一个缓存就好了。
@bssn 啊，我觉得管 post 和 index 就足够了呀，其实自己给那些独立的 page 加上缓存也不难的。
我争取努力一下，把博客做到需要安装缓存插件的程度……
因為使用了不少php判斷客戶端信息顯示的語句，注定了我不能用此類緩存插件。。前幾天剛把wp super cache撤銷了～
@Leeiio 呵呵有得必有失吧
呃，我想問下你的“我的留言”是如何實現的？
@Leeiio 根据 cookie 判断访问者有没有留过言，如果有，在数据库中查出最新的 10 条显示出来。
我还是觉得super-cache是不打扰PHP脚本的。它只是让htaccess做了一下rewrite而已，我没有看出什么地方用到php的。你可以看看super-cache的htaccess文件。
super cache是apache转发过的生成静态html的机制,与cos-html-cache没有本质上的区别.
相反的因为cos-html-cache不根据不同的博客进行缓存,会造成不支持mu的wordpress.局限了使用范围.
个人认为生成html+apache的rewrite才是比较好的解决方案.
super cache的问题是garbage的时间太短了,你可以选择改代码改的时间长一点,这样可以稍微提高效率.
@海妖的夜
我验证过是有区别的： http://hellobmw.com/archives/wordpress-plugin-wp-super-cache.html
嗯，暂时用不上静态缓存，学习一下~
才看到这篇文章，wp-super-cache自从升到新版后，居然在ie下就能访问了，不知是什么鸟原因，我现在去试下这个插件看能不能访问正常。还有我想了解下那个使用 JavaScript 来验证 cookie的方法，不知有没有相关的文章啊
@北极冰仔
思路真清晰..
我启用 这个插件了 但是始终 没在wp-cache里生成任何文件 = =！ 怎么检查这个插件 启用运作了呢。
还有 开启这个插件后GZIP将失效 后台的 开启GZIP 也没用。。
插件设置界面 也没任何提示错误 我就是用不了 （看不到生成的文件）
还有 看到很多 安装方法都不一样 。。。有个 这样说的 。
安装方法
1.上传插件（如果先前安装过其他缓存插件的，请先彻底卸载）
2.把插件中的advanced-cache.php放到wp-content文件夹里。并把wp-content文件夹和advanced-cache.php的权限设为777
3.别忘了给wp-config.php加上一句define(’WP_CACHE’, true);
。。。。汗了 。帮我下吧
Hyper Cache和MobilePress等Wordpress手机插件的兼容性有问题
hyper cache 我升级了两次，结果两次升级完之后整个插件消失，郁闷的，又要重新安装过插件