MediaWiki中生成gzip压缩的静态HTML缓存文件
--James Qi 2010年2月25日 (四) 10:41 (CST)
很早前我们的Wiki网站中就使用静态HTML缓存文件来让浏览者访问更快、MySQL数据库压力更小，实践中对于大流量、内容复杂的网站来说，这是很有效果的。
不过对于内容太多的网站还有一个问题，就是生成的HTML文件数量实在太多了，占用的磁盘空间很大，例如一个有30万页面的网站，占用磁盘空间大约为：300,000 * 100KB = 30G，而如果有300万个页面的话，就会占用300G，这实在不是一个小数字。
除了简化网页内容来减小HTML文件以外，还有个办法，就是启用Gzip压缩功能，以前我曾经试过，但好像遇到点乱码问题就终止了，昨天再次测试，依然有乱码问题，找到MediaWiki的官方网站，查看一些信息后，对LocalSettings.php中做了一些修改，现在解决了。设置如下：
$wgUseFileCache = true; #启用文件缓存功能，这个以前就打开了 $wgUseGzip = true; #新设置这个变量，对缓存文件进行Gzip压缩 $wgDisableOutputCompression = true; #遇到乱码后需要将这个变量进行设置，去掉Apache的双重Gzip压缩
这样在cache目录中看到的就是.html.gz的压缩文件了，我的情况是对于一般的30K左右的HTML文件来说可以压缩到10K左右，而对于200K左右的大HTML文件来说可以压缩到40K左右，也就是启用Gzip压缩后磁盘占用只有以前的20%-30%左右，这无疑是很不错的效果！
MediaWiki默认启用了Apache的Gzip压缩功能，也就是说传送以前的.html静态文件本来也耗用了CPU资源来压缩，现在改为保存成.html.gz文件，这个压缩过程会使用CPU资源，再对外传送的时候应该不需要再耗用CPU资源了，所以应该不会增加CPU的消耗。（这个是我的想象，还没有很明确的证实）
这样修改后，目前网站访问都正常，前端的Squid没有做什么修改，好像没有特别的反应，应该缓存命中率等都不会影响吧，这个不知道对不对。
唯一我担心的是以前我们为了找出生成HTML的时候遇到报错的情况，同事编写了脚本每天凌晨对HTML文件进行扫描检查，发现尺寸过小、内容包含报错关键词的.html文件就删除，而现在使用.html.gz后就没有办法用这个脚本了，除非修改这个脚本，但进行逐个解压扫描报错关键词的话，估计CPU工作量更大了。初步准备还是在MediaWiki中设置缓存过期时间进行定期更新来解决这个问题。
| 标签：MediaWiki、Gzip、HTML、缓存。 |
相关内容：
|
