Jump to: navigation, search

Other languages:
Deutsch • ‎English • ‎español • ‎日本語 • ‎português • ‎русский

MediaWiki is a very complex web-application, which 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 compulsory, 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 degrade performance.

Short version: we recommend you use APC and memcached; this is what the Wikimedia Foundation uses for Wikipedia et al. See Manual:Performance tuningManual:Performance tuning.

PHP bytecode caching[edit]

PHP works by compiling a PHP file into bytecode and then executing that bytecode. The process of compiling the file into bytecode takes some time. PHP accelerators work by storing the compiled bytecode and executing it directly reducing the time spent compiling code. Some PHP accelerators:

  • OPcache is included in PHP 5.5.0 and later. Recommended.
  • APC (Alternative PHP cache) caches PHP bytecode and provides object caching services to PHP applications. APC is available as a package from many Linux distributions (e.g. Ubuntu 10.04) and PECL. See Manual:APCManual:APC. APC is not recommended if OPcache is available. For object caching, use APCu then instead.
  • XCache. After Debian installation with apt-get install php5-xcache, set xcache.var_size to be >0M (e.g. 16M). Otherwise it may lead to an error.

MediaWiki does not need to be configured to do PHP caching and 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.

Object caching[edit]

When MediaWiki assembles a page to show to a user, it performs database queries to gather lots of different pieces of data and then combines it all into the page. Object caching allows MediaWiki to store these combined objects for later retrieval reducing the time spent communicating with the database and assembling pages. This is arguably the most important cache for most installations. MediaWiki can store the cached objects in a number of different places including on a file system, in the database, or in an external caching system like memcachedmemcached, APC (APCu if OPcache is available) or XCache.

Since MediaWiki 1.18.0, you can define your own caching system using $wgObjectCachesManual:$wgObjectCaches.

On a single server[edit]

If you have a PHP object cache such as APC(u) or XCache, you can easily use this to store all of the extra data. This is strongly recommended, and requires the following line in LocalSettings.phpLocalSettings.php:

$wgMainCacheType = CACHE_ACCEL;

If you are unable to use such a cache, then you may be able to use memcachedmemcached, see that page for details. This is considerably more complicated, but still very effective.

Note that you should not use CACHE_ACCEL or memcached in shared hosting as these caches are shared between vhosts.

The other two types of object cache use a database for caching. This may (or may not) be better than nothing, but one of the previous two solutions should be tried first.

$wgMainCacheType = CACHE_DB;

On multiple servers[edit]

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

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

Disabling caching[edit]

$wgMainCacheType = CACHE_NONE;

Localisation caching[edit]

New in 1.16

After finding out 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. It uses the database l10n cacheManual:l10n cache table table by default. Set $wgCacheDirectoryManual:$wgCacheDirectory in LocalSettings.phpLocalSettings.php to a valid path to use a local caching instead. See Localisation#CachingLocalisation#Caching for more details.

Anecdotally, this one change worked wonders for my low use intranet wiki. www-data is the user for Apache on Ubuntu/Debian. Specify your actual webserver user:group, e.g. on Gentoo you would put apache:apache instead of www-data:data:

mkdir /var/cache/wiki
chown www-data:www-data /var/cache/wiki
chmod 700 /var/cache/wiki

add this to LocalSettings.php:

$wgCacheDirectory= "/var/cache/wiki";

Page caching[edit]

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 a single server[edit]

You may use varnishManual:Varnish caching/squidManual:Squid caching, 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 cacheManual:file cache, detailed instructions are on that page.

On multiple servers[edit]

If you have multiple application servers running MediaWiki in a load-balanced configuration, use an existing HTTP-level cache, such as varnishManual:Varnish caching or squidManual:Squid caching.

Interwiki cache[edit]

MediaWiki has a database table (interwikiManual:Interwiki table table) for interwiki prefixes. This is by default used directly, but caching can be used for better performance. See Interwiki cacheInterwiki cache.

See also[edit]

CacheCategory:Cache Category:Performance tuningCategory:Performance tuning