Manual:Performance tuning/ru

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

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



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

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



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

PHP


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

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

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

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

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

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



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



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

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

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

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

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



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

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



Одиночный веб-сервер
Если у вас установлен APC, настоятельно рекомендуется использовать его, установив следующие параметры в :

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

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

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

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

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



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

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



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



Кэш локализации
По умолчанию переводы интерфейсных сообщений кэшируются в таблице базы данных. Ensure in  is set to a valid path to use a local caching instead. See Help:System message#Caching for more details.

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

Page view caching
Page view caching increases performance tremendously for anonymous (not logged-in) users. It does not affect performance for logged-in users.

Caching proxy
A caching proxy (or "HTTP accelerator") stores a copy of web pages generated by your web server. When such page is requested a second time, then the proxy serves up its local copy, instead of passing the request onto the real web server.

This massively improves the response times for page loads by end users, and also tremendously reduces the computational load on the MediaWiki web server. When a page is edited, MediaWiki can automatically purge the local copy from the cache proxy.

Examples of cache proxies:
 * Varnish Cache, this is currently (as of November 2018) used by Wikipedia. See also Manual:Varnish caching.
 * Squid, this was used by Wikipedia prior to 2012.
 * Apache's mod_cache_disk, see this article for instructions with MediaWiki.

File cache

 * See for main article about this.

In absence of a caching proxy or HTTP accelerator, MediaWiki can optionally use the file system to store the output of rendered pages. For larger sites, using an external cache like Varnish is preferable to using the file cache.

Web server

 * if you use Apache as web server, use PHP-FPM, not mod_php. PHP-FPM optimizes re-use of PHP processes.
 * switch Apache to use the event MPM instead of the prefork MPM.
 * adjust robots.txt to disallow bots from crawling history pages. This decreases general server load.
 * HTTP/2 protocol can help, even with ResourceLoader.

Configuration settings
Large sites running MediaWiki 1.6 or later should set to a low number, say 0.01. See for more information.

Composer
MediaWiki uses composer for organizing library dependencies. By default these are included from the  directory using a dynamic autoloader. This autoloader needs to search directories which can be slow. It is recommended to generate a static autoloader with Composer, which will make your wiki respond faster.

Using a static autoloader is the default for all MediaWiki installations from the tarball download or from Git. If for some reason this is not the case, use the following to generate the static autoloader:

composer update -o --no-dev

Remember that this will need to be re-run after each MediaWiki update as it includes a static copy of which libraries and classes exist in the software.

MySQL
For a heavy concurrent write load, InnoDB is essential. Use memcached, not the default MySQL-based object cache.

See below for some DB configuration tricks. You can also try and run the mysql-tuning-primer script to get some quick statistics and suggestions.

Multiple servers
The database software and web server software will start to fight over RAM on busy MediaWiki installations that are hosted on a single server. If your wiki has a consistent traffic, a logical step, once other performance optimizations have been made (and cache serves most of the content), is to put the database and web server on separate servers (or, in some cases, multiple separate servers, starting with a replica.) Also:


 * check that MySQL has query cache enabled and enough memory;
 * give most memory to innodb_buffer_pool;
 * add cores for MySQL if maxed out at peak times;
 * give memcached even more RAM for in-memory cache.

Benchmarking
Some tools can help quickly evaluate the effects of performance tuning.


 * http://webpagetest.org is "real life" testing, commanded in your browser.
 * ab is a command line tool which quickly produces some nice stats.
 * PageSpeed



См. также

 * http://dammit.lt/2007/01/26/mediawiki-performance-tuning/ : APC and a few simple settings that boost performance
 * More extensive changes, sacrificing some functionality
 * How to make MediaWiki fast
 * Comprehensive MediaWiki performance optimisation (mostly redundant with this page and what above)
 * User:Ilmari Karonen/Performance tuning, focusing on small wikis
 * Use cases:
 * Wikipedia: Site internals, configuration, code examples and management issues [PDF, 2007]
 * Caching, minification, domain-sharing and compression techniques used by WikiFur
 * Для разработчиков:
 * Журнал и
 * Глава по производительности Норта
 * Специальная документация Викимедиа:
 * Руководство по производительности бэкенда команды Wikimedia Performance Team
 * Руководство по производительности фронтенда команды Wikimedia Performance Team