Manual:File cache/ja

MediaWikiには、記事ページのレンダリングされたHTMLをキャッシュするためのオプションの単純なスキームがあります.

操作と使用
ファイル キャッシュを有効にするには、LocalSettings.php 内で3つの変数に設定します:

= true; /* 既定値: false */ = "$IP/cache"; # または既定値のままにしておきます: "{$wgUploadDirectory}/cache"の既定値は"$IP/images/cache"

これにより、ウィキの各ページのレンダリングされたHTML Webページがハードディスク上の個々のファイルに保存されます. その後の匿名ユーザーのリクエストは、ページを再表示するのではなく、ディスクに保存されているHTMLバージョンを送信するだけで満たされます. これにより時間が節約されます.

生成したHTMLウェブテキストはディスク上の の下位ディレクトリに保存されます.

 -rw-r--r-- 1 apache apache 57421 Jan 7 01:58 cache/0/04/P%C3%A1gina_principal.html -rw-r--r-- 1 apache apache 29608 Jan 4 16:37 cache/1/17/P%C3%A1gina_Riscada.html -rw-r--r-- 1 apache apache 21592 Jan 3 07:27 cache/1/1c/P%C3%A1gina_Duplicada.html -rw-r--r-- 1 apache apache 36088 Jan 7 02:03 cache/2/24/P%C3%A1gina_principal_alternativa.html -rw-r--r-- 1 apache apache 44205 Jan 7 06:10 cache/a/a4/P%C3%A1gina_linkada.html -rw-r--r-- 1 apache apache 24686 Jan 3 07:27 cache/d/db/P%C3%A1gina_Invertida.html -rw-r--r-- 1 apache apache 17222 Jan 3 06:28 cache/f/f0/P%C3%A1gina_n%C3%A3o_encontrada.html

この例ではファイルはcache/ ディレクトリにキャッシュされ、保存されたウィキのページにはPágina ... という一連の名称が与えられ1件ずつPágina_....htmlを取得します. これらのファイルは、ユーザーがウィキ上のファイルにアクセスするたびに生成されるもので、rebuildFileCache.phpのmaintenance scriptを使用すると一括して生成できます.

ファイルキャッシュは積極的にキャッシュする傾向があり、キャッシュされたページに有効期限は設定されておらず、ページに変数、拡張子およびその他の変更可能な出力が含まれていても、無条件にキャッシュします. 特定の拡張機能は、動的コンテンツを持つページのファイルキャッシュを無効にします.

より効果的な結果を得るには$wgUseGzipを代用するか、組み合わせて使用することを検討してください.

規模が大きなサイトでは、ファイルキャッシュにSquidあるいはVarnish等、外部のキャッシュの利用が望まれます.

ファイルキャッシュが機能していないと思ったら、指定したディレクトリがウェブサーバの書き込みを許可しているかどうか確認してください.

制限
キャッシュファイルのファイル名は、ページのタイトルに従って決定されます. ページ題名の使用言語により、ファイルシステムにおいて有効なファイル名を生成するため、特定の文字のエンコードが必要な場合があります. アラビア語、中国語などの言語の場合、次のようなPHP警告が表示されることがあります:

PHP Warning: file_put_contents(cache/......html.gz): failed to open stream: File name too long in includes/cache/FileCacheBase.php on line 171

これは既知の制限です. を参照してください.

カテゴリおよび画像の説明ページは、ファイルキャッシュからパージされません. たとえば、カテゴリからページを追加または削除してもカテゴリページは更新されないため、ログインしていないユーザーはカテゴリページの変更を見ることができません. これは既知の制限です. を参照してください.

ドメインと範囲
キャッシュ処理が可能なユーザーの対象:
 * ログインしていない.
 * user_newtalkのフラグを無効にしてある.

キャッシュする対象のページとは:
 * 特別ページではない.
 * リダイレクトではない.
 * 現在のバージョンで閲覧でき、明示され、urlパラメータを使用していない.

これでウィキに対する要求の大部分をカバーできるものの、その他の項目の処理にはバイトコードとソフトウェアのキャッシュ処理の設定が重要です.

検証
キャッシュしたファイルの変更時刻は、各ビューので設定されたグローバルな$ CacheEpochタイムスタンプと比較されます.

もしファイルの保存費付けがこれらと同じであれば有効と判断され、クライアントへ直接送られます. 日付が古いもしくは存在しない場合、パーシングとレンダリングが続行して将来の利用のために記録されます.

無効化
を現在時刻に設定するか、キャッシュのファイルをすべて削除すると、全キャッシュを無効にできます.

個々のページの無効化にはpage.page_touchedフィールドの更新を行い、 を呼び出すと簡便に実行できます. （編集リンクの更新のため）新規記事の作成や編集の保存、改名やリンク記事の作成・削除のたびに、これを必ず行ってください. 例えばテンプレートの編集による無効化の操作は、page_touchedとキャッシュ日付を照合するテンプレートを採用するページを確認します.

事例によっては以下のように、まだ適切に処理されていません.


 * ブラウザの〈再読み込み〉あるいは〈リフレッシュ〉（更新せずに同じページをリロードする）
 * output variables from extensions such as Extension:DynamicPageList disable filecache for those pages to avoid stale data. Those that don't will return stale data even on browser refresh.
 * certain long error messages may be cached indefinitely as if they were valid page content; only ?action=purge will remove these from the file cache once stored. A minimum output size threshold is used to avoid caching most errors, like fatal PHP errors.

関連項目:

有効期限
There should probably be some method of expiration of cache pages, particularly for pages containing variables (it is X date, we have X articles, etc).

If  is -1, file caching will be disabled for the output of the page. There is no provision to set an expiry time, so all HTML for all pages is cached forever. An explicit ?action=purge command (or an edit to the page) will regenerate that one page, but neither the MediaWiki internal no-cache flags nor the browser refresh will remove outdated extension output once it has been stored as part of a file-cached page.

更新タブ
It is possible to add a tab to force one individual page to be invalidated and refreshed by using ?action=purge using the Purge page extension.

圧縮
Optionally, the cache may be compressed to save space and bandwidth. (This requires that zlib be enabled in the PHP config.)

If compression is enabled, the cache files are saved as .html.gz. Browsers that advertise support for gzip in their Accept-Encoding field will be given the gzipped version straight; for those browsers that don't, we unzip the data on the fly and send them the plaintext.

A "Vary: User-agent" header will be sent to tell proxy caches to be more careful about who it resends data to. ("Vary: Accept-encoding" would be more appropriate, but Internet Explorer refuses to cache pages so marked.)

緊急時のフォールバック
If the wiki can't contact the database server, it will try to show the cached version of whatever page was requested, regardless of whether it may be current or not, with a "database is down" message tacked into it.

This has some limitations:
 * special pages are not covered in any way, there's just a warning message
 * redirect pages are not cached, so clicking a link to a redirect doesn't go through to the final destination
 * pages with colons in the title (other than for a valid namespace) may still fail due to MediaWiki checking the DB to see if the title has a valid interwiki prefix. This occurs only if there is no interwiki cache entry for the page's prefix (see ) or   is falling back (or set to).
 * attempts to use non-view actions result in a plain page view, which may be confusing
 * there may be issues with the MySQL connection timeout which make it take prohibitively long before giving up, particularly if using persistent connections and the db dies later. Adjust mysql.connect_timeout (set to 3 or more) in php.ini to deal with this. Edit the webserver's php.ini not the cli php.ini.
 * fallback may fail if  is not "true" due to attempting a DB query
 * fallback may fail if  is set to "cache" and   is falling back (or set to) DB_CACHE

キャッシュされたページを直接提供する
By default, Mediawiki passes cache page with php. Here is how we use webserver configuration tricks to serve cached files directly without invoking MediaWiki or PHP at all.

First, setting. Then we add rewrite rules. See below.

Apache
次のmod_rewriteルールは、Apache 2.2を実行している共有Webホストの.htaccessファイルで動作することが確認されています.

 RewriteBase / RewriteCond %{HTTP_COOKIE} !UserID= RewriteCond %{QUERY_STRING} !. RewriteCond %{DOCUMENT_ROOT}/w/html_cache/$1.html -s RewriteRule ^wiki/(.+)$ /w/html_cache/$1.html [B,L,NS]
 * 1) If a cached page exists under /w/html_cache, do an internal redirect to it:

However, this rewrite rule won't work properly for pages whose titles contain punctuation or non-ASCII characters. A tidy solution would be to use a RewriteMap, but this is not supported in .htaccess context. Instead, the following trick can be used to handle non-ASCII titles by pulling the URL-escaped title directly from the raw request line:

 RewriteBase / RewriteCond %{HTTP_COOKIE} !UserID= RewriteCond %{QUERY_STRING} !. ReWriteCond %{THE_REQUEST} ^GET\x20/wiki/([^\x20/]+)\x20HTTP RewriteCond %{DOCUMENT_ROOT}/w/html_cache/%1.html -s RewriteRule ^wiki/(.+)$ /w/html_cache/%1.html [B,L,NS]
 * 1) If a cached page exists under /w/html_cache, do an internal redirect to it:

This will still not match titles containing periods, slashes or other punctuation which the file cache escapes but browsers don't (or vice versa). One should also ensure that the appropriate Vary header gets sent:

Header append Vary Cookie

Also note that, since this redirect trick bypasses MediaWiki entirely, it won't respect. You may need to clear or rebuild the cache manually as needed instead.

Nginx
Since the nginx configuration language is pretty limited (it doesn't allow nested if statements, for example), it requires the ngx_lua module.

The following conf should be integrated inside your server block, and it assumes that:
 * you're using fancy urls like example.com/Page;
 * your cache folder is inside your MediaWiki folder (default);
 * you're already proxying *.php files to php-fpm (or whatever) in the last location block.

And here are the limitations:
 * as with the Apache solution, you have to run a cron job or manually rebuild the cache files when they change;
 * pages whose title include non-ASCII characters are served through PHP (which should be transparent to the user anyway).

必要に応じてパスを変更してください.