Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a MediaWiki installation and are getting complaints that it is becoming slower. How can we increase the speed / performance?

I have one tip (which I'll add below) but I'm really interested in hearing more. Preferably one tip per answer.

share|improve this question
Here's a useful link I found: – Wikis Nov 12 '10 at 10:25
Or the more comprehensive and recent – Nemo Apr 9 '15 at 9:13

Instead of memory caching especially if your site is small to medium size, so the total size of of all the hmtl pages isn't an issue - a simple solution is to just switch on the file cache instead.

I spent several hours today trying to switch on any of the mediawiki recommended memory caching solutions on my shared hosting (at bluehost) and found no way to do it, and then discovered this option and it solved all the issues.

This is the wiki with file caching switched on:

Before file caching it took several seconds to load most pages, and sometimes much longer, up to minutes according to the Google analytics logs.

share|improve this answer
up vote 2 down vote accepted

Switch on caching in LocalSettings.php. Do this by adding / changing this line:

$wgMainCacheType = CACHE_ACCEL;

See Manual:Cache and this mwusers page.

share|improve this answer

First of all you have to Be sure That You use Apache Server'''. Mediawiki is slower if you have installed on Windows Server Or IIS. If it is on the Windows Server Move the Application Folders to Linux Server. Windows and Linux Server for Mediawiki Guide

share|improve this answer

Some great tips here. For me the thing that made the biggest difference (from 8 seconds to 0 on IIS 7) was enabling caching and changing $wgDBserver = ""; (from localhost). For some reason localhost was being resolved via the network.

Here is the whole post by Jaded:

  1. One of the biggest impacts, reducing the load from 15 seconds down to around 6 or 7 was to enable Mediawiki caching and acceleration, as detailed in this post: In short, enable the following in your Mediawiki localsettings.php file:

    $wgCacheDirectory = "c:\your\path\to\cache";
    $wgFileCacheDirectory = "c:\your\path\to\cache ";
    $wgEnableSidebarCache = true;
    $wgUseFileCache = true;
    $wgShowIPinHeader = false;
    $wgEnableParserCache = true;
    $wgCachePages = true;
    $wgMainCacheType = CACHE_ACCEL;
    $wgMessageCacheType = CACHE_ACCEL;
    $wgParserCacheType = CACHE_ACCEL;
    $wgMemCachedServers = array();

    Make sure your local IUSR and IIS_IUSR accounts have "Modify" permissions on the cache directory, or else the files and directories from Mediawiki caching engine will not be able to write to them.

  2. I made some minor changes to caching in PHP using Wincache, but that hardly had any affect - enable and configure it if you wish from a PHP perspective, but don't expect a major jump. The same thing goes for MySQL query caching - my Wiki site is relatively small, with minimum usage, so MySQL query caching wasn't a huge improvement.

  3. The final nail in the coffin to bring the site up to speed was modifying the $wgDBserver setting in my Mediawiki LocalSettings.php file. It was set to "Localhost", and this post suggested that using "Localhost" on Windows 7 onwards, and Server 2008 onwards starts getting IPv6 involved in the querying of the page. The transport layer had to resolve localhost and was doing so by negotiating between an IPv4 and an IPv6 address, which PHP and MySQL needed to resolve before allowing the page to render. It appears that this is still not a fully supported integrated protocol, so setting $wgDBserver to the IPv4 address of "" took the rendering from 6 seconds to just on 1 second - problem solved!

share|improve this answer

This may not be relevant with current versions of MW, but check the php setting mbstring.func_overload. I set it to 2 (as a re-requisite for a small zabbix installation) and it killed the performance of a 1.12 install of MW on the same server.

share|improve this answer
thx! Will check it out. – Wikis Nov 12 '10 at 10:53
according to mbstring.func_overload This option causes errors and may corrupt data unpredictably; MediaWiki will refuse to install if this option is turned on. So I guess this is not applicable. – Wikis Nov 19 '10 at 10:50

Use a php opcode cacher, make sure dB is not the bottleneck, consider using a http cacher like varnish.

share|improve this answer
can you give me a bit more detail here? E.g. links, how to know whether the DB is the bottleneck, what an http cacher is? I'm not that knowledgeable of the back end details. – Wikis Nov 12 '10 at 19:59
Google for, or use from, they'll tell you if you need to beef up buffers, if queries are running slow etc. Varnish is a reverse proxy type service which can cache dynamic web pages, the learning curve is a bit steep but it's a high end service so it's really worth checking out. The order of how you should investigate is (a part from the obvious like network throughput) probably 1) opcode cacher 2) determine how db is doing/performing and 3) varnish. – 3molo Nov 12 '10 at 20:04
Mediawiki even have an article about caching with varnish! – 3molo Nov 12 '10 at 20:04
Forgot to mention that mediawiki also suggests using memcached for caching between the database and the actual site, see – 3molo Nov 12 '10 at 20:06
OK, thanks will check these out. – Wikis Nov 19 '10 at 10:28

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.