Manual:Performance tuning/ja

このページではMediawikiのパフォーマンスを改善するいくつかの方法について概要を記しています.

背景
MediaWiki is capable of scaling to meet the needs of large wiki farms such as those of Wikimedia Foundation, WikiHow and FANDOM and can take advantage of a wide number of methods including multiple load-balanced database servers, memcached object caching, Varnish caches (see Manual:Varnish caching) and multiple application servers. For most smaller installations, this is overkill though, and simply enabling object caching and optimizing PHP performance should suffice.

簡単な始め方
短く：PHPにはバイトコードキャッシュ、ローカルオブジェクトキャッシュにはAPCu、メインキャッシュにはMemcachedをお勧めします. これは、ウィキメディア財団がウィキペディアなどに使用しているものです.

場合によっては、あまりにも多くのレベルでの過剰なキャッシュにより、パフォーマンスが低下する可能性があります.

Puppetを使った簡単な始め方
Most of the tweaks on this page have been collected in a puppet manifest ( and ). If you install Puppet, you can apply them to your server with a single command.

バイトコードキャッシュ

 * See PHP configuration

PHP works by compiling a PHP file into bytecode and then executing that bytecode. MediaWikiなどの大規模なアプリケーションをコンパイルするプロセスにはかなりの時間がかかります. PHPアクセラレーターは、コンパイルされたバイトコードを保存して直接実行することで機能し、コードのコンパイルにかかる時間を短縮します.

OPcache is included in PHP 5.5.0 and later and the recommended accelerator for MediaWiki. サポートされているその他のオペコードキャッシュは次のとおりです. WinCache.

オペコードキャッシュは、PHPスクリプトのコンパイル済み出力を保存し、スクリプトを複数回実行するために必要な時間を大幅に短縮します. MediaWikiは、PHPバイトコードキャッシュを実行するように構成する必要はなく、インストールして有効にすると「正常に機能」します.

オブジェクトキャッシュ
For more information about local server, main cache and other cache interfaces, see Manual:Caching.

ローカル サーバー
このインターフェースは、Webサーバー上で直接軽量キャッシュを行うために使用されます. このインターフェースは、Web要求間で保存された値を保持することが期待されています.

サポートされているバックエンドの存在は、MediaWikiによって自動的に検出されます. '''MediaWikiの設定は必要ありません. '''

For PHP 7+, you should install APCu or WinCache. (On PHP 5, APCu was known to be unstable in some cases. )

APCuをインストールするには、以下を使用します.

A script,  is bundled with the APCu package which can be used to inspect the status of the cache, and also examine the contents of the user cache to verify that MediaWiki is correctly using it.

メインキャッシュ
このインターフェイスは、より大きなオブジェクトのメインオブジェクトキャッシュとして使用されます.

メインキャッシュはデフォルトで無効になっているため、手動で構成する必要があります. To enable it, set to a key in. There are preconfigured interfaces for Memcached, APC, and MySQL. You can configure additional backends via (e.g. for Redis).

Single web server
If you have APC installed is strongly recommended to use that by setting the following in :

Once set, the user session store and parser output cache will also inherit this MainCacheType setting.

When using APC with limited RAM (and no Memcached or other object cache configured), then important objects might be evicted too often due to the size of parser output cache building up. Consider setting to CACHE_DB, which will move those keys out to the database instead.

If using  and users are unable to login due to "session hijacking" errors, consider overriding   to. See task T147161 for more info.

If you can't use APC, consider installing (requires at least 80MB of RAM). While installing Memcached is considerably more complicated, it is very effective.

If neither APC or Memcached is an option, you can fallback to storing the object cache in your database. The following preset will do that:

Multiple web servers
If your MediaWiki site is served by multiple web servers, you should use a central Memcached server. Detailed instructions are on the  page.

It is important that you do not use APC as the main cache for multiple web servers, as this cache is expected to be coordinated centrally for a single MediaWiki installation. Having each web server use APC as its own MainCache will cause stale values, corruption or other unexpected side-effects. Note that for values that are safe to store in uncoordinated fashion (the "local-server cache"), MediaWiki automatically makes use of APC regardless of this configuration setting.

Interwiki cache
MediaWiki interwiki prefixes are stored in the  database table. See Interwiki cache for how to cache these in a CDB or PHP file.

Localisation cache
By default, interface message translations are cached in the database table. Ensure in  is set to a valid path to use a local caching instead. See for more details.

ページ閲覧キャッシュ
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:

See also Squid on Wikitech.
 * 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.

複数のサーバ
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.

ベンチマーク
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
 * (removed in MediaWiki 1.35)

関連項目

 * http://dammit.lt/2007/01/26/mediawiki-performance-tuning/ : APC and a few simple settings that boost performance


 * More extensive changes, sacrificing some functionality
 * User:Aaron Schulz/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
 * For developers:
 * Logging and
 * North's Performance chapter