给一部 MediaWiki 提速的完整旅程

主站是一座 MediaWiki。它曾经慢到影响收录——搜索引擎来抓搜索页,等到超时。这篇把整条提速之路记下来,给同病相怜的站长。

第一阶段查到的根因很荒诞:站点的缓存后端配置成了数据库。一次匿名的站内搜索,产生一万三千多条缓存查询 SQL,页面耗时四到十秒。换成内存缓存之后,匿名文章页的渲染直接快了一倍多,有严格的 A/B 实测数字。这里埋着一个后来的坑:缓存模块是临时装进容器里的,容器一重建它就蒸发,而且静默蒸发——性能回退了一天,没人发现。从此定了一条规矩:每天定时探测缓存模块是否存活,丢了就在日志里喊出来。

第二阶段查到的是一张膨胀的表。全文搜索的索引表,正常两千行上下,因为当天上百次批量编辑不断追加增量段,索引文件膨胀到一百多兆,搜索初始化被拖到五到十五秒。重建一遍表,回到二十几兆,耗时回落到两秒上下。由此立下运维约定:批量导入之后,必须重建搜索索引。

第三阶段才是根治。前两阶段治的都是症状,真正的病灶是数据库全文搜索对中文的先天不适:长查询要走逐词 AND,几秒到二十几秒,还隐藏着一个超过十个词就五百的硬伤。最终上了正规的搜索扩展加搜索引擎的组合,期间还填了一个版本匹配的深坑——新搜索扩展只兼容特定版本的开源搜索引擎,而官方索引模板用到的分析过滤器在那个版本里没有构建,只能给核心代码打补丁绕过。

终局数字:最刁钻的长中文查询,从八到二十二秒降到零点五五秒;压测下引擎本体四百多次每秒,整页搜索的天花板也足够真实流量十倍余量。

方法论沉淀就三句话:慢日志常常不可靠,要靠分段打点自己抓现场;数据库的进程状态和索引文件大小,是最诚实的两位证人;性能优化的每一分收益,都要有 A/B 数字背书,没有数字的优化是玄学。