Manual:File cache/zh

MediaWiki有一个缓存条目的HTML代码的可选缓存方案.



操作和使用
文件缓存只为匿名用户服务，他们看到的是相同的HTML渲染. 已登录用户不能用这个缓存，因为他们的页面包含了用户名、选择的皮肤等.

文件缓存是通过在LocalSettings.php中设置和参数启用的：

这将导致wiki的每个页面的渲染HTML网页存储在硬盘上的单个文件中. 匿名用户的任何后续请求都不会通过再次呈现页面来满足，而是通过发送存储在磁盘上的HTML版本来满足. 这节省了时间.

生成的HTML web文本存储在 下的目录中的磁盘中，看起来有点像：

 -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/”，存储的wiki页面命名为“Página …”，生成一个对应的“Página_…”. html文件. 这些文件将在用户访问wiki上的文章时创建；您可以使用维护脚本一次性创建它们.

文件缓存倾向于积极缓存；缓存的页面没有设置到期日期，即使页面包含变量、扩展名和其他可变输出，也会无条件缓存. 某些扩展禁用具有动态内容的页面的文件缓存.

考虑使用代替或组合使用，以获得更有效的结果.

对于较大的站点，使用外部缓存（如squid或varnish）比启用文件缓存更好.

如果文件缓存似乎不工作，请确保Web服务器具有写入所选目录的权限.

限制
缓存文件的文件名由相应的页面标题决定. 根据页面标题中使用的语言，必须对文件名中的某些字符进行编码，以构成相应文件系统的有效文件名. For languages like Arabic, Chinese and so on this may result in the following PHP warning:

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参数

这涵盖了对wiki的大多数请求，但设置字节码和应用程序缓存来处理其余的请求仍然很重要.

驗證
缓存文件的修改时间与每次访问上设置为的全局 时间戳进行比较.

如果文件至少与这两个文件一样新，则认为它是有效的，并直接发送给客户端. 如果它较旧或不存在，将继续分析和渲染，并保存结果以供将来使用.

验证
通过将 设置为当前时间或删除缓存中的所有文件，可以使整个缓存无效.

通过更新其page.page_touched字段，单个页面将失效，调用可以方便地完成. 这应该在文章创建、编辑保存、重命名以及链接文章的创建和删除（以便更新编辑链接）时完成. 编辑模板时发生的无效操作，例如，检查使用模板将缓存日期与page_touched进行比较的页面.

Some cases are not yet handled properly, which probably includes:

Those that don't will return stale data even on browser refresh. A minimum output size threshold is used to avoid caching most errors, like fatal PHP errors.
 * browser 'reload' or 'refresh' (just reloads same cached page without updates)
 * output variables from extensions such as disable filecache for those pages to avoid stale data.
 * 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.

Also see:.

過期
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 , 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  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.

Refresh tab
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.)

Emergency fallback
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.

這有一些限制：


 * 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   due to attempting a DB query
 * fallback may fail if  is set to   and   is falling back (or set to) DB_CACHE

Serving cached pages directly
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
The following mod_rewrite rule has been found to work in an  file on a shared webhost running Apache 2.2:

 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:

The previous rewrite rules will handle requests of the form

https://site/wiki/Page_Name

To handle requests where the Page_Name is in the QUERY_STRING like

https://site/w/index.php?title=Page_Name

the following works:

 RewriteCond %{HTTP_COOKIE} !UserID= RewriteCond %{QUERY_STRING} ^title=([^&]+)$ RewriteCond %{DOCUMENT_ROOT}/images/cache/ns0\%3A%1.html -s RewriteRule ^ /images/cache/ns0\%253A%1.html? [B,L,NS]

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.

并且這有一些限制：


 * 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).

Change paths as needed.

Code stewardship
