View source for Manual:File cache/hu

<languages />
<div lang="en" dir="ltr" class="mw-content-ltr">
MediaWiki has an optional simplistic scheme for caching the rendered HTML of article pages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Operation and usage ==
</div>
<span lang="en" dir="ltr" class="mw-content-ltr">The file cache serves anonymous users only and they see the same HTML rendered.</span> 
<span lang="en" dir="ltr" class="mw-content-ltr">Logged-in users don't benefit from this cache because their page contains user name, selected skin, etc.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
The '''file cache''' is enabled by setting {{ll|Manual:$wgUseFileCache|$wgUseFileCache}} and {{ll|Manual:$wgFileCacheDirectory|$wgFileCacheDirectory}} variables in LocalSettings.php:
</div>

<syntaxhighlight lang="php">
$wgUseFileCache = true; // default: false
$wgFileCacheDirectory = "$IP/images/cache"; // default: "{$wgUploadDirectory}/cache" which equals to "$IP/images/cache"
</syntaxhighlight>

<div lang="en" dir="ltr" class="mw-content-ltr">
This causes the rendered HTML webpage for each page of the wiki to be stored in an individual file on the hard disk. Any subsequent requests from anonymous users are met not by rendering the page again, but by simply sending the stored HTML version which is on the disk. This saves time.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The generated HTML web text is stored to disk in directories under the <code>$wgFileCacheDirectory</code> and looks somewhat like:
</div>

<pre style="overflow:auto;">
-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
</pre>

<span lang="en" dir="ltr" class="mw-content-ltr">In this example, the file cache directory is ''cache/'' and the stored wiki pages are named ''Página ...'', yielding one corresponding ''Página_...''.html file for each.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">These files will be created as users visit articles on the wiki; you can create them all in one go with the {{ll|Manual:rebuildFileCache.php|rebuildFileCache.php}} [[Special:MyLanguage/Manual:Maintenance scripts|maintenance script]].</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
The file cache tends to cache aggressively; there is no set expiry date for the cached pages and pages are cached unconditionally even if they contain variables, extensions and other changeable output. Some extensions disable file cache for pages with dynamic content.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Consider using {{ll|Manual:$wgUseGzip|$wgUseGzip}} instead or in combination for much more effective results.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For larger sites, the use of an external cache such as [[Special:MyLanguage/Manual:Squid caching|Squid]] or [[Special:MyLanguage/Manual:Varnish caching|Varnish]] is preferable to enabling the file cache.
</div>

Ha a fájlgyorsító tár nem úgy tűnik, hogy működik, biztosítsd, hogy a webszerver rendelkezik a választott könyvtárba való írási engedéllyel.

<div lang="en" dir="ltr" class="mw-content-ltr">
== Limitations ==
</div>
<span lang="en" dir="ltr" class="mw-content-ltr">The file names of the cache files are determined by the according page titles.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Depending on the language, which is used in the page titles, some characters in the file names will have to be encoded in order to make up a valid file name for the according file system.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">For languages like Arabic, Chinese and so on this may result in the following PHP warning:</span>

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

Ez egy ismert korlát.
<span lang="en" dir="ltr" class="mw-content-ltr">See {{phabricator|T148684}}.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">Category and image description pages aren't purged from file cache.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">For example, adding or removing a page from a category doesn't update the category page, causing not logged in users to not see the changes in the category page.</span>
Ez egy ismert korlát.
<span lang="en" dir="ltr" class="mw-content-ltr">See {{phabricator|T26575}}</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Domain and range ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Caching is only done for users who:
* are not logged in.
* do not have their [[Special:MyLanguage/user newtalk table|user_newtalk]] flag active.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Caching is only done for pages which:
* are not special pages.
* are not redirects.
* are being viewed in current version, plain view, no url parameters
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This covers the majority of requests to the wiki, but it is still important to set up [[Special:MyLanguage/Manual:Cache|bytecode and application caching]] to handle the rest.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Validation ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The modification time of the cached file is compared with the global <code>{{ll|Manual:$wgCacheEpoch|$wgCacheEpoch}}</code> timestamp set in {{ll|Manual:LocalSettings.php|LocalSettings.php}} on each view.
</div>

Ha a fájl legalább olyan új, mint mindkettő, érvényesnek számít, és közvetlenül a kliensnek lesz elküldve. Ha régebbi vagy nem létezik, az értelmezés és leképezés folytatódik, és az eredmények későbbi használatra lesznek elmentve.

<div lang="en" dir="ltr" class="mw-content-ltr">
=== Invalidation ===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The entire cache can be invalidated by setting <code>$wgCacheEpoch</code> to the current time, or by deleting all files in the cache.
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">Individual pages are invalidated by updating their [[Special:MyLanguage/Page table#page_touched|page.page_touched]] fields, conveniently done by calling {{phpi|Title::invalidateCache()}}.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">This should be done on article creation, edit saves, renames, and creation and deletion of linked articles (in order to update edit links).</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Invalidation operations that occur when editing templates, for example, check pages that use template to compare the cache date against page_touched.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
Some cases are not yet handled properly, which probably includes:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* browser 'reload' or 'refresh' (just reloads same cached page without updates)
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* output variables from extensions such as {{ll|Extension:DynamicPageList}} disable filecache for those pages to avoid stale data.
</div> <span lang="en" dir="ltr" class="mw-content-ltr">Those that don't will return stale data even on browser refresh.</span>
<div lang="en" dir="ltr" class="mw-content-ltr">
* 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.
</div> <span lang="en" dir="ltr" class="mw-content-ltr">A minimum output size threshold is used to avoid caching most errors, like fatal PHP errors.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
Also see: {{ll|Manual:$wgInvalidateCacheOnLocalSettingsChange}}.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
=== Expiration ===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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).
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">If {{phpi|$parserOutput->getCacheTime()}} is <code>-1</code>, file caching will be disabled for the output of the page.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">There is no provision to set an expiry time, so all HTML for all pages is cached forever.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">An explicit <code>?action=purge</code> 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.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Refresh tab ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It is possible to add a tab to force one individual page to be invalidated and refreshed by using ?action=purge using the [[Special:MyLanguage/Extension:Purge|Purge page extension]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Compression ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Optionally, the cache may be compressed to save space and bandwidth. (This requires that zlib be enabled in the [[Special:MyLanguage/PHP config|PHP config]].)
</div>

<syntaxhighlight lang="php">
$wgUseGzip = true;
</syntaxhighlight>

<span lang="en" dir="ltr" class="mw-content-ltr">If compression is enabled, the cache files are saved as .html.gz.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">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.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">A "Vary: User-agent" header will be sent to tell proxy caches to be more careful about who it resends data to.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">("Vary: Accept-encoding" would be more appropriate, but Internet Explorer refuses to cache pages so marked.)</span>

{{warning|1=<span lang="en" dir="ltr" class="mw-content-ltr">Do not enable <code>{{ll|Manual:$wgUseGzip|$wgUseGzip}}</code> if you have output buffering enabled that gzips the content (via <code>ob_gzhandler</code> or <code>zlib.output_compression</code>). Doing so will result in gibberish being shown to users.</span>}}

<div lang="en" dir="ltr" class="mw-content-ltr">
== Emergency fallback ==
</div>
{{outdated}}
<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has some limitations:
</div>

* <span lang="en" dir="ltr" class="mw-content-ltr">special pages are not covered in any way, there's just a warning message</span>
* <span lang="en" dir="ltr" class="mw-content-ltr">'''redirect pages are not cached, so clicking a link to a redirect doesn't go through to the final destination'''</span>
* <span lang="en" dir="ltr" class="mw-content-ltr">'''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 <code>{{ll|Manual:$wgInterwikiExpiry|$wgInterwikiExpiry}}</code>) or <code>{{ll|Manual:$wgMainCacheType|$wgMainCacheType}}</code> is falling back (or set to) <code>DB_CACHE</code>.</span>
* <span lang="en" dir="ltr" class="mw-content-ltr">attempts to use non-view actions result in a plain page view, which may be confusing</span>
* <span lang="en" dir="ltr" class="mw-content-ltr">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.</span>
* <span lang="en" dir="ltr" class="mw-content-ltr">fallback may fail if <code>{{ll|Manual:$wgStatsMethod|$wgStatsMethod}}</code> is set to <code>cache</code> and <code>$wgMainCacheType</code> is falling back (or set to) DB_CACHE</span>


<div lang="en" dir="ltr" class="mw-content-ltr">
== Serving cached pages directly ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
First, setting <code>{{ll|Manual:$wgFileCacheDepth|$wgFileCacheDepth}} = 0;</code>. Then we add rewrite rules. See below.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Apache===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following [http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html mod_rewrite] rule has been found to work in an <code>.htaccess</code> file on a shared webhost running Apache 2.2:
</div>

<pre style="overflow:auto;">
RewriteBase /
# If a cached page exists under /w/html_cache, do an internal redirect to it:
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]
</pre>

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

<pre style="overflow:auto;">
RewriteBase /
# If a cached page exists under /w/html_cache, do an internal redirect to it: 
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]
</pre>

The previous rewrite rules will handle requests of the form

<pre style="overflow:auto;">https://site/wiki/Page_Name</pre>

To handle requests where the Page_Name is in the QUERY_STRING like

<pre style="overflow:auto;">https://site/w/index.php?title=Page_Name</pre>

the following works:

<pre style="overflow:auto;">
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]
</pre>

<span lang="en" dir="ltr" class="mw-content-ltr">This will still not match titles containing periods, slashes or other punctuation which the file cache escapes but browsers don't (or vice versa).</span>
<span lang="en" dir="ltr" class="mw-content-ltr">One should also ensure that the appropriate Vary header gets sent:</span>

<pre style="overflow:auto;">Header append Vary Cookie</pre>

<span lang="en" dir="ltr" class="mw-content-ltr">Also note that, since this redirect trick bypasses MediaWiki entirely, it won't respect <code>{{ll|Manual:$wgCacheEpoch|$wgCacheEpoch}}</code>.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">You may need to clear or rebuild the cache manually as needed instead.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
===Nginx===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Since the nginx configuration language is pretty limited (it doesn't allow nested if statements, for example), it requires the [http://wiki.nginx.org/HttpLuaModule ngx_lua module].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following conf should be integrated inside your server block, and it assumes that:
</div>

* <span lang="en" dir="ltr" class="mw-content-ltr">you're using fancy urls like example.com/Page;</span>
* <span lang="en" dir="ltr" class="mw-content-ltr">your cache folder is inside your MediaWiki folder (default);</span>
* <span lang="en" dir="ltr" class="mw-content-ltr">you're already proxying *.php files to php-fpm (or whatever) in the last location block.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
And here are the limitations:
</div>

* <span lang="en" dir="ltr" class="mw-content-ltr">as with the Apache solution, you have to run a cron job or manually rebuild the cache files when they change;</span>
* <span lang="en" dir="ltr" class="mw-content-ltr">pages whose title include non-ASCII characters are served through PHP (which should be transparent to the user anyway).</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
Change paths as needed.
</div>

<syntaxhighlight lang="lua" style="overflow:auto;">
 location ~ /cache/(.*) {
     internal;
 }
 
 location / {
     default_type 'text/html';
     rewrite_by_lua '
         local cookie = ngx.req.get_headers()["Cookie"] or ""
         if string.match(cookie, "UserID") then  -- if we are logged in...
             ngx.exec("@rewrite")
         else
             local page = string.sub(ngx.var.request_uri, 2, -1)  -- get the page name without the leading slash
             local filename = page .. ".html"
             local f = io.open("/var/www/w/cache/" .. filename, "r")
             if f ~= nil then  -- if the file exists, close it and serve it directly
                 io.close(f)
                 ngx.header["x-wiki-cache"] = "via nginx"  -- headers to help you debug
                 ngx.exec("/cache/" .. filename)
             else
                 ngx.header["x-wiki-cache"] = "via mediawiki"
                 ngx.exec("@rewrite")
             end
         end
     ';
 }
  
 location @rewrite {
     rewrite ^/([^?]*)(?:\?(.*))? /index.php?title=$1&$2 last;
 }
</syntaxhighlight>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Code stewardship ==
</div>

{{Component|mediawiki-core-http-cache}}

<div lang="en" dir="ltr" class="mw-content-ltr">
==See also==
</div>
* {{ll|Manual:Configuration settings}}

[[Category:MediaWiki development{{#translation:}}|File cache]]
[[Category:Cache{{#translation:}}|File cache]]
[[Category:Performance tuning{{#translation:}}]]