Manual:Performance tuning/ja

From Linux Web Expert

このページでは、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 (puppet/modules/role/manifests/simple_performant.pp and puppet/modules/role/manifests/simple_miser.pp). If you install Puppet, you can apply them to your server with a single command.

PHP

バイトコードキャッシュ

See PHP configuration#Opcode caching.

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 is the recommended accelerator for MediaWiki. その他にサポートされているオペコードキャッシュはWinCacheです。

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

MediaWiki 1.36以降、OPコードキャッシュがないシステムでは遅くなることがあります。 <translate> task <tvar name=1>T274041</tvar></translate> を参照してください。

オブジェクトキャッシュ

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.[1])

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

sudo apt-get install php-apcu php-igbinary

A script, apc.php 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 $wgMainCacheType to a key in $wgObjectCaches . Memcached、APC、およびMySQL用に事前構成されたインターフェースがあります。 バックエンドは$ObjectCaches経由で追加設定できます（例：Redis用）。 

// Default:
// $wgMainCacheType = CACHE_NONE;

単一のWebサーバー

If you have APC installed is strongly recommended to use that by setting the following in LocalSettings.php : 

$wgMainCacheType = CACHE_ACCEL;

設定すると、ユーザーセッションストアとパーサーの出力キャッシュもこのMainCacheType設定を継承します。

APC を限られた RAM で使用する場合 (そして Memcached や他のオブジェクト キャッシュが設定されていない場合)、パーサーの出力キャッシュのサイズが大きくなるため、重要なオブジェクトが頻繁に追い出される可能性があります。 Consider setting $wgParserCacheType to CACHE_DB, which will move those keys out to the database instead.

If using $wgMainCacheType = CACHE_ACCEL; and users are unable to login due to "session hijacking" errors, consider overriding $wgSessionCacheType to CACHE_DB. See task T147161 for more info.

If you can't use APC, consider installing Memcached (requires at least 80MB of RAM). Memcachedのインストールはかなり複雑ですが、非常に効果的です。

APCとMemcachedのどちらもオプションでない場合は、データベースにオブジェクトキャッシュを保存するようにフォールバックできます。 次のプリセットはそれを行います: 

$wgMainCacheType = CACHE_DB;

複数のウェブサーバ

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

It is important that you do not use APC as your main cache if you have multiple web servers. This cache must 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.

インターウィキキャッシュ

MediaWiki interwiki prefixes are stored in the interwiki database table. See インターウィキのキャッシュ for how to enable caching.

キャッシュの場所

By default, interface message translations are cached in the l10n_cache database table. Ensure $wgCacheDirectory in LocalSettings.php 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). $wgEnableSidebarCache および $wgSidebarCacheExpiry を参照してください。

ページ閲覧キャッシュ

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

キャッシングプロキシ

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.

キャッシュプロキシの例:

ファイルキャッシュ

See Manual:ファイル キャッシュ 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.

ウェブサーバー

  • if you use Apache as web server, use PHP-FPM, not mod_php. PHP-FPM optimizes re-use of PHP processes.
    • プリフォークMPMの代わりにイベントMPMを使用するようにApacheを切り替えます。
  • robots.txt を調整して、ボットが履歴ページをクロールできないようにします。 これにより、一般的なサーバーの負荷が軽減されます。 See Manual:robots.txt .
  • HTTP/2 protocol can help, even with ResourceLoader.[2]

環境設定

Large sites running MediaWiki 1.6 or later should set $wgJobRunRate to a low number, say 0.01. See Manual:ジョブ キュー for more information.

Composer

PHPで opcache を有効にした場合、何のメリットもありません。

MediaWiki uses composer for organizing library dependencies. By default these are included from the /vendor directory using a dynamic autoloader. このオートローダーは、低速になる可能性のあるディレクトリを検索する必要があります。 Composerを使用して静的オートローダーを生成することをお勧めします。これにより、Wikiの応答が速くなります。

静的オートローダーの使用は、tarballダウンロードまたはGitからのすべてのMediaWikiインストールのデフォルトです。 何らかの理由でこれが当てはまらない場合は、以下を使用して静的オートローダーを生成します。 

composer update -o --no-dev

これは、ソフトウェアに存在するライブラリとクラスの静的コピーが含まれているため、MediaWikiを更新するたびに再実行する必要があることに注意してください。

データベースの設定

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.

複数のサーバ

データベースソフトウェアとWebサーバーソフトウェアは、単一のサーバーでホストされているビジーなMediaWikiインストールでRAMを介して戦い始めます。 ウィキに一貫したトラフィックがある場合、他のパフォーマンスの最適化が行われた後（そしてキャッシュがほとんどのコンテンツを提供する）、論理的なステップは、データベースとWebサーバーを別々のサーバー（または場合によっては複数の別々のサーバー）に配置することです、レプリカから始めます。） 関連項目：

ベンチマーク

一部のツールは、パフォーマンスチューニングの効果をすばやく評価するのに役立ちます。

関連項目

参照

  1. ↑ APCu GitHub issue 19: Hung apaches on pthread wrlocks
  2. ↑ Niklas Laxström, Performance is a feature, December 9th, 2013.
Retrieved from "https://www.linuxwebexpert.com/wiki/index.php?title=Manual:Performance_tuning/ja&oldid=31181"