Руководство:Настройка производительности

На этой странице представлен обзор различных способов повышения производительности MediaWiki.

Контекст

MediaWiki способна масштабироваться для удовлетворения потребностей крупных вики-ферм, таких как Фонд Викимедиа, WikiHow и Фэндом, и может использовать преимущества большого количества методов, включая несколько серверов баз данных с балансировкой нагрузки, кэширование объектов memcached, кэширование Varnish (см. [[Manual:Varnish caching |Руководство:Кэширование Varnish]]) и несколько серверов приложений. Однако для большинства небольших установок это излишне, достаточно просто включить кэширование объектов и оптимизировать производительность PHP.

Быстрый старт

Краткая версия: Мы рекомендуем кэш байт-кода для PHP, APCu в качестве локального объектного кэша, Memcached для основного кэша; именно это использует Фонд Викимедиа для Википедии и др.

В некоторых случаях избыточное кэширование на слишком большом количестве уровней может ухудшить производительность.

Быстрый старт с Puppet

Большинство настроек на этой странице были собраны в манифесте puppet (puppet/modules/role/manifests/simple_performant.pp и puppet/modules/role/manifests/simple_miser.pp). Если вы установили Puppet, вы можете применить их к своему серверу с помощью одной команды.

PHP

Кэширование байт-кода

См. Конфигурация PHP#Кэширование опкода.

PHP работает путем компиляции PHP-файла в байт-код и последующего выполнения этого байт-кода. Процесс компиляции большого приложения, такого как MediaWiki, занимает значительное время. Ускорители PHP работают, сохраняя скомпилированный байт-код и выполняя его напрямую, сокращая время, затрачиваемое на компиляцию кода.

OPcache включен в PHP 5.5.0 и более поздние версии и является рекомендуемым ускорителем для MediaWiki. Другими поддерживаемыми кэшами операционного кода являются: WinCache.

Кэши опкодов хранят скомпилированный вывод PHP-скриптов, что значительно сокращает время, необходимое для многократного запуска скрипта. MediaWiki не нужно настраивать на кэширование байткода PHP, он будет "просто работать" после установки и включения.

Начиная с MediaWiki 1.36, она может работать медленнее на системах без кэширования оп-кода. Смотрите задача T274041.

Кэширование объектов

Для получения дополнительной информации о локальном сервере, основном кэше и других интерфейсах кэша см. раздел Руководство:Кэширование.

Локальный сервер

Этот интерфейс используется для легкого кэширования непосредственно на веб-сервере. Предполагается, что этот интерфейс будет сохранять хранимые значения во время веб-запросов.

Наличие поддерживаемого бэкенда автоматически определяется MediaWiki. Настройка MediaWiki не требуется.

Для PHP 7+ следует установить APCu или WinCache. (На PHP 5 было известно, что APCu в некоторых случаях работает нестабильно.)

Чтобы установить APCu, используйте:

sudo apt-get install php-apcu php-igbinary

Скрипт, apc.php в комплекте с пакетом APCu, который может быть использован для проверки состояния кэша, а также для проверки содержимого пользовательского кэша, чтобы убедиться, что MediaWiki правильно его использует.

Основной кэш

Этот интерфейс используется в качестве основного кэша объектов для больших объектов.

По умолчанию основной кэш отключен и должен быть настроен вручную. Чтобы включить его, установите $wgMainCacheType на ключ в $wgObjectCaches . Имеются предварительно настроенные интерфейсы для Memcached, APC и MySQL. Вы можете настроить дополнительные бэкенды через $ObjectCaches (например, для Redis).

// Default:
// $wgMainCacheType = CACHE_NONE;

Одиночный веб-сервер

Если у вас установлен APC, настоятельно рекомендуется использовать его, установив следующие параметры в LocalSettings.php :

$wgMainCacheType = CACHE_ACCEL;

После установки кэш пользовательской сессии и кэш вывода парсера также наследуют этот параметр MainCacheType.

При использовании APC с ограниченным объемом оперативной памяти (и без настроенного Memcached или другого кэша объектов), важные объекты могут удаляться слишком часто из-за увеличения размера кэша вывода парсера. Рассмотрите возможность установки $wgParserCacheType в CACHE_DB, что приведет к перемещению этих ключей в базу данных.

Если при использовании $wgMainCacheType = CACHE_ACCEL; пользователи не могут войти в систему из-за ошибок "перехвата сеанса", подумайте о переопределении $wgSessionCacheType на CACHE_DB. Более подробную информацию см. в задании T147161.

Если вы не можете использовать APC, подумайте об установке Memcached (требуется не менее 80 МБ оперативной памяти). Хотя установка Memcached значительно сложнее, она очень эффективна.

Если ни APC, ни Memcached не подходят, вы можете вернуться к хранению кэша объектов в базе данных. Следующая предварительная настройка сделает это:

$wgMainCacheType = CACHE_DB;

Несколько веб-серверов

Если ваш сайт MediaWiki обслуживается несколькими веб-серверами, вам следует использовать центральный сервер Memcached. Подробные инструкции приведены на странице memcached .

Важно, чтобы вы не использовали APC в качестве основного кэша, если у вас несколько веб-серверов. Этот кэш должен быть согласован централизованно для одной установки MediaWiki. Использование каждым веб-сервером APC в качестве собственного MainCache приведет к появлению устаревших значений, повреждению или другим неожиданным побочным эффектам. Обратите внимание, что для значений, которые можно хранить несогласованно ("кэш локального сервера"), MediaWiki автоматически использует APC, независимо от этого параметра конфигурации.

Кеш интервики

Префиксы interwiki MediaWiki хранятся в таблице базы данных interwiki . О том, как включить кэширование, см. в статье Interwiki cache .

Кэш локализации

По умолчанию переводы интерфейсных сообщений кэшируются в таблице базы данных l10n_cache . Убедитесь, что $wgCacheDirectory в LocalSettings.php имеет правильный путь, чтобы вместо него использовать локальное кэширование. Более подробную информацию смотрите в Help:System message#Caching.

Sidebar cache

A small save in DB queries can be obtained by caching the sidebar (disabled by default). See $wgEnableSidebarCache and $wgSidebarCacheExpiry .

Кэширование просмотра страниц

Кэширование просмотра страниц значительно повышает производительность для анонимных (не вошедших в систему) пользователей. Это не влияет на производительность для вошедших в систему пользователей.

Кэширующий прокси

Кэширующий прокси (или "HTTP-ускоритель") хранит копии веб-страниц, созданных вашим веб-сервером. Когда такая страница запрашивается во второй раз, прокси предоставляет свою локальную копию, вместо того чтобы передавать запрос на реальный веб-сервер.

Это значительно улучшает время отклика при загрузке страниц конечными пользователями, а также значительно снижает вычислительную нагрузку на веб-сервер MediaWiki. Когда страница редактируется, MediaWiki может автоматически очищать локальную копию из кэш-прокси.

Примеры кэш-прокси:

• Кэширование Varnish, в настоящее время (по состоянию на ноябрь 2018 года) используется Википедией. См. также Руководство:Кэширование Varnish.
• Squid, использовался в Википедии до 2012 года.
• Apache's mod_cache_disk, смотрите эту статью для получения инструкции по работе с MediaWiki.

Файловый кэш

См. основную статью об этом Manual:File cache .

В отсутствие кэширующего прокси или HTTP-ускорителя, MediaWiki может опционально использовать файловую систему для хранения результатов рендеринга страниц. Для больших сайтов использование внешнего кэша, такого как Varnish, предпочтительнее, чем использование файлового кэша.

Веб-сервер

• если вы используете Apache в качестве веб-сервера, используйте PHP-FPM, не mod_php. PHP-FPM оптимизирует повторное использование процессов PHP.
  • переключить Apache на использование event MPM вместо prefork MPM.
• настройте robots.txt, чтобы запретить ботам просматривать страницы истории. Это снижает общую нагрузку на сервер. See Руководство:Robots.txt .
• Протокол HTTP/2 может помочь даже с ResourceLoader.

Конфигурационные настройки

Крупные сайты, работающие под управлением MediaWiki 1.6 или более поздней версии, должны установить $wgJobRunRate на низкое число, скажем, 0.01. Для получения дополнительной информации см. Руководство:Очередь задач .

Composer

Это не принесет никакой пользы, если вы включите opcache в PHP.

MediaWiki использует composer для организации зависимостей библиотек. По умолчанию они включаются из каталога /vendor с помощью динамической автозагрузки. Эта автозагрузка требует поиска в каталогах, что может быть медленным. Рекомендуется генерировать статическую автозагрузку с помощью Composer, что позволит вашей вики отвечать быстрее.

Использование статического автозагрузчика является стандартом по умолчанию для всех установок MediaWiki из tarball или из Git. Если по какой-то причине это не так, используйте следующее для генерации статического автозагрузчика:

composer update -o --no-dev

Помните, что его нужно будет запускать заново после каждого обновления MediaWiki, так как он включает статическую копию того, какие библиотеки и классы существуют в программе.

Конфигурация базы данных

MySQL

При большой одновременной нагрузке на запись InnoDB незаменим. Используйте memcached, а не кэш объектов на основе MySQL по умолчанию.

О некоторых приемах настройки БД см. ниже. Вы также можете попробовать запустить скрипт mysql-tuning-primer для получения быстрой статистики и предложений.

Несколько серверов

Программное обеспечение базы данных и программное обеспечение веб-сервера начнут бороться за оперативную память на загруженных установках MediaWiki, размещенных на одном сервере. Если ваша вики имеет постоянный трафик, то логичным шагом, после того как будут проведены другие оптимизации производительности (и кэш обслуживает большую часть контента), будет размещение базы данных и веб-сервера на отдельных серверах (или, в некоторых случаях, на нескольких отдельных серверах, начиная с реплики). Также:

• проверьте, что MySQL имеет включенный кэш запросов и достаточно памяти;
• отдать большую часть памяти пулу innodb_buffer_pool;
• добавить ядра для MySQL, если он максимально загружен в пиковое время;
• дать memcached еще больше оперативной памяти для внутрипамятного кэша.

Сравнительный анализ

Некоторые инструменты могут помочь быстро оценить эффект от настройки производительности.

• http://webpagetest.org - это тестирование в "реальной среде", проводимое в вашем браузере.
• ab - это инструмент командной строки, который быстро выдает несколько хороших статистических данных.
• PageSpeed

См. также

• http://dammit.lt/2007/01/26/mediawiki-performance-tuning/ : APC и несколько простых настроек, повышающих производительность
• Более масштабные изменения, жертвуя некоторой функциональностью
  • Как сделать MediaWiki быстрее
  • Комплексная оптимизация производительности MediaWiki (в основном избыточна по отношению к этой странице и тому, что выше)
• User:Ilmari Karonen/Performance tuning, ориентируясь на небольшие вики
• Примеры использования:
  • Википедия: Внутреннее устройство сайта, конфигурация, примеры кода и вопросы управления [PDF, 2007]
  • Кэширование, минификация, совместное использование доменов и методы сжатия используемые WikiFur
• Для разработчиков:
  • Журнал и Руководство:Профилирование
  • Глава по производительности Норта
• Специальная документация Викимедиа:
  • Руководство по производительности бэкенда команды Wikimedia Performance Team
  • Руководство по производительности фронтенда команды Wikimedia Performance Team