Прошлая попытка обновления Mediawiki-движков на JabberWorld.info и linuxoid.in закончилась без особого успеха. Сейчас снова вернулся к теме — и то ли в конфиге сервера что-то поменялось, то ли из-за обновления через консоль, но все же удалось успешно обновиться сначала до 1.39, а потом и до текущего (1.43) LTS. Чуть поменялся конфиг: потребовалось убрать инклуд DefaultSettings.php, а также старое определение минимальной длины пароля.
В целом, апдейт через консоль оказался даже удобнее — не приходится заново прописывать в веб-интерфейсе данные подключения к базе и прочую информацию, мимо которой не пройти в установщике. Скопировал LocalSettings.php и .htaccess — и можно запускать maintenance/run.php update. Потом (если надо) развернуть новую версию и повторить.
Интереснее стало другое. В процессе общения с гугло-ИИ и изучения опций движка Mediawiki открыл для себя встроенную возможность кэширования и отдачи сгенерированных статических HTML-страниц. В процессе изучения docker’а на машине с AMD C60 и тестирования развернутых сервисов на используемых на «большом» сервере сайтах особенно заметна «тяжесть» и неповоротливость Mediawiki и WordPress (даже с учетом давно уже использующегося memcached), поэтому любая тема с ускорением этих монстров была интересна. В общем, включаем:
$wgUseFileCache = true;
$wgFileCacheDirectory = "$IP/cache/html";
$wgCacheDirectory = "$IP/cache";
$wgUseLocalMessageCache = true;
Каталог cache существует штатно для каких-то там нужд, подкаталог html создастся автоматически. Собственно и все — после этого внутри каталога html начнут сохраняться сгенерированные статичные страницы при визитах от незалогиненных пользователей. При повторном визите если движок находит уже сохраненную страницу, то отдает ее, а не дергает базу. При желании можно даже отдавать веб-сервером напрямую эти страницы, в обход движка. Кроме того, можно не дожидаться создания страниц, а делать это по cron’у скриптом maintenance/rebuildFileCache.php. Для понимания масштаба снижения нагрузки по двум вики и блогу (о нем ниже) — графики с Munin:
В общем, ощутимо, и нагрузка снижается по нескольким направлениям сразу: база сама по себе (нагрузка на проц); не вымывается кэш запросов у базы; PHP — нет необходимости снова генерировать данные; быстрее отдаем запрос — меньше надо держать рабочих процессов, меньше затраты памяти.
Явно выраженные пики на второй части графика — работа Tiny Tiny RSS, т.е., без него график вообще стремился бы к нулю.
По блогу — на волне настройки статики в MW спросил гуглоИИ насчет того, что можно использовать для WordPress, но без кардинальных изменений в стиле плагина Simply Static (нравится мне этот плагин, но хотелось бы сохранить штатные функции движка, а не прикручивать отдельный поисковик к HTML-страничкам). И среди рекомендаций было знакомое название — W3 Total Cache. Я его уже использую, но исключительно для работы с memcached. Как оказалось, при настройке слегка перестарался и включил работу с memcached в том числе там, где не надо. Поправил по подсказкам нужные настройки — стали создаваться статичные странички в wp-content/cache/page_enhanced/rain.linuxoid.in — соответственно, memcached на сейчас используется только для того, что реально требуется кэшировать в нем.
В целом, по трем сайтам общий объем статичных страниц на сейчас колеблется в районе 100-110 МБ. Отдача страничек явно ускорилась. На сейчас самым тяжелым сайтом остался Nextcloud (и да, там уже используется memcached и Opcache).
И да, MW жиреет прямо на глазах: занимаемое место увеличилось на несколько сотен МБ. Такими темпами придется переключаться на Mediawiki Core (который без плагинов и прочего) и делать «свою» сборку под задачу.