我已经在具有 root 访问权限的专用服务器(24 核、32GB RAM、RAID 1)上实现了 Mediawiki 1.35。
该实例包含 2100 多万篇文章,其中一些文章很大,包含多个无法进一步优化的脚本调用。因此,一些页面生成需要 30 多秒才能完成,有时脚本会超时并退出不完整,这从 UX 角度来看显然是不可接受的。
为了缓解这个问题,我按照以下方式启用了 gzip 文件缓存官方文档效果很好。通过运行官方文件缓存生成脚本我可以在 30 天内缓存所有页面(作为一次性事件)。但是,默认的缓存策略是在编辑文章时删除缓存的项目(当然,因为数据已经过时了),但是提交编辑时不会重新生成新的缓存文件。因此,第一个请求该页面的匿名用户必须等待缓存完成,并产生上述问题。wiki 的编辑者很少,但匿名读者很多。
我想要一个解决方案,在编辑文章时自动重新生成页面的缓存文件。有没有一种相当简单的方法可以挂接到编辑过程的末尾并调用重新生成缓存文件,或者其他一些简单的方法?如果可能的话,我宁愿不增加(比如)Varnish 或其他反向代理缓存的复杂性,但会考虑任何可行的选择。
短暂性脑缺血发作
答案1
您可以尝试调整HtmlCacheUpdater
处理这些清除的服务:
use MediaWiki\MediaWikiServices;
$wgHooks['MediaWikiServices'][] = function ( MediaWikiServices $services ) {
$services->addServiceManipulator( 'HtmlCacheUpdater', function ( HtmlCacheUpdater $updater, MediaWikiServices $services ) {
return new class() extends HtmlCacheUpdater {
public function purgeTitleUrls( $pages, $flags = self::PURGE_PRESEND, array $unless = [] ) {
$ret = parent::purgeTitleUrls( $pages, $flags, $unless );
DeferredUpdates::addCallableUpdate( function () use ( $pages ) {
foreach ( $pages as $page ) {
$title = MediaWikiServices::getInstance()->getTitleFactory()->castFromPageReference( $page );
$article = new Article( $title );
$context = new DerivativeContext( $article->getContext() );
$output = new OutputPage( $context );
$output->disable();
$context->setOutput( $output );
$article->setContext( $context );
$article->view();
}
} );
return $ret;
}
};
} );
};
请记住,这是脆弱的、未经测试的、为主人编写的 -castFromPageReference
在 1.37 中是新的,所以至少那部分需要有点不同。