Manual:Cache

MediaWiki is a very complex web-application, this means that it can take some time to render pages. To mitigate these costs, many MediaWiki administrators install one of many caching solutions. They are by no means compulsary, though they can decrease the time it takes pages to load, and decrease server workload. This page is divided into four sections, in order to cache everything, you need to enable a solution from each group. It is very likely that you do not need to cache everything, simply enable things that you can, until you have acceptable performance. In some cases, over-caching will cause a degradation of performance.

PHP caching
The first thing MediaWiki does when it runs is to read all the PHP files it needs. As there are hundreds of files needed to handle even simple requests, caching these files in a form that is quicker to read helps. There are pre-existing tools that do this for you:


 * APC (Alternative PHP cache). This is available as a package from many linux distributions, or from PECL, and is recommended.
 * PHP accelerator.
 * eAccelerator.

MediaWiki does not need to know about this, and it will "just work" if you install any of them. You can use phpinfo to verify that the cache is installed and configured properly. More information is available from these projects, and google is your friend!

Object caching
While running, MediaWiki needs a lot of data to create a page. Normally all of this data has to come from the database, or from potentially expensive operations. Caching all this data (in the "object cache") will help. This is arguably the most important cache for most installations.


 * On a single server
 * If you have a PHP byte-code cache, see PHP caching above, you can easily use this to store all of the extra data. This is strongly recommended, and requires the following line in LocalSettings.php:
 * If you are unable to use such a cache, then you may be able to use memcached, see that page for details. This is considerably more complicated, but still very effective.
 * The other two types of object cache use a daatabase for caching. This may (or may not) be better than nothing, but one of the previous two solutions should be tried first.
 * The other two types of object cache use a daatabase for caching. This may (or may not) be better than nothing, but one of the previous two solutions should be tried first.


 * On multiple servers
 * If you have multiple application servers running MediaWiki in a load-balancing configuration, you need to use memcached, detailed instructions are on that page.

If you set $wgMainCacheType then the values for $wgParserCacheType and $wgMessageCacheType will inherit it. You do not need to set those variables unless you plan on doing something very advanced.

Localization caching

 * New in 1.16

On the observation that a large number of the cached objects above were interface messages, the bits of text that are not content, an advanced localisation cache was introduced. If you wish to take advantage of it set $wgCacheDirectory appropriately.

Page caching
Once the entire page has been rendered, it is often served multiple times, identically, to not-logged-in users. There is no need to ask MediaWiki to repeat itself.


 * On multiple servers
 * If you have multiple application servers running MediaWiki in a load-balanced configuration, use an existing HTTP-level cache, such as varnish or squid.


 * On a single server
 * You may use varnish/squid, as above, or leverage any support your web-server has for HTTP caching. If this is not an option, for example you are on a shared host, then consider enabling the file cache, detailed instructions are on that page.