MediaWiki:Performance

From Glitchdata
Jump to navigation Jump to search

Here are some options to improve MediaWiki speed. Improved performance is good for SEO.

  • Enable Main Cache
  • Enable File Cache
  • Install APC
  • Install Memcache
  • Apache mod_disk_cache


Enable File Cache

Simplest performance generator. Steps to do this are:

  • Edit LocalSettings.php
 $wgUseFileCache = true; /* default: false */
 $wgFileCacheDirectory = "$IP/cache";
 $wgShowIPinHeader = false; 

Enable Main Cache

Step to do this are:

  • Edit LocalSettings.php
  • Use this only if you have eAccelerator installed.
 $wgMainCacheType = CACHE_ACCEL;

Install APC

Install Alternative PHP Cache (APC)

Install Memcache

Install memcache:

Enable Apache mod_disk_cache

This is a webserver optimisation:

$wgUseFileCache = true; /* default: false */
$wgFileCacheDirectory = "$IP/cache";
$wgShowIPinHeader = false; 

Enable HTTP Caching

Squid servers provide HTTP caching capability

Opcode Caching

Opcode caches the PHP-compiled scripts. Software that does this is:

  • APC
  • eAccelerator (no longer supported since MW1.19)
  • mmTurck
  • WinCache
  • XCache;
  • See $wgMainCacheType


HipHop

HipHop Virtual Machine is a JIT for PHP developed by and used in production at Facebook. HHVM is not a magic bullet, but has favorable performance characteristics compared to Zend. HHVM support isn't complete in MediaWiki, and should not be attempted by the faint hearted.

Upgrade Diff

Set $wgDiff and $wgDiff3 to gnu diff utility (download as needed). This is recommended. The default PHP diff code is slow and crashy.

Parsing Reduction

  • Edit the MediaWiki:Aboutsite and MediaWiki:Pagetitle system messages by changing Glitchdata into your site name. This avoids extra parsing on each hit.

Disable Counters

MediaWiki keeps a track of how many times a page has been viewed. So, every time a page is requested –the page view count of that page is incremented in database. If keeping track of page views is not important for you, you should switch off this functionality to save database calls. To disable page view counters, add the following line in LocalSettings.php

$wgDisableCounters = true;

Note: If you’re using caching, keeping counters on will not be of use anyway because in most cases the requested page will delivered to the users from cache and database update will not take place.

Set Hit Counter Frequency

In case pageview counters are of great importance to you, you should make use of variable $wgHitcounterUpdateFreq. If you really need hitcounters, use $wgHitcounterUpdateFreq instead of the $wgDisableCounters setting above.

This variable sets the frequency of how often pageview counters are updated. By default, it has a value of 1 –which means update is done everytime a page is viewed. You should set it to something like 500. This would mean that the database will be updated only once after 500 pageviews. To set this variable, use the following in LocalSettings.php

$wgHitcounterUpdateFreq = 500;

Enable Miser Mode

MediaWiki can run in a “miser mode” wherein it disables a number of features to save resources and enhance performance. Following are the things that enabling miser mode does:

  • Disables custom formatting of change sizes in Special:RecentChanges via MediaWiki:Rc-change-size (r48986)
  • Disables selecting all pages that start with x box on Special:log (and leprefix option of list=logevents API module)
  • Totally disables special:MimeSearch, as well as aimime and famime option in the list=allimages and list=filearchive API module
  • Disables showsizediff option of the RSS feed for Special:Contributions
  • In the list=categorymembers and list=externallinks API module, use reduced sorting by namespace mode (returns only a few results when cmnamespace or elnamespace option is in use).
  • Similarly disables the filter by namespace box on Special:LinkSearch
  • Disables showing list of most popular pages on special:Statistics (But still will show other page view statistics if counters are on)
  • Doesn’t update number of active users quite as often (?)
  • Disables the search for images with x somewhere in their name box on special:NewImages and special:ListFiles
  • Do not show how many previous versions of an image were uploaded on Special:ListFiles
  • When running rebuildrecentchanges.php maintenance script, will not re-auto-patrol edits by users with auto-patrol flag.
  • When running updateCollations.php maintenance script, will not tell you how many rows in total there are to update.

To enable miser mode, add the following in LocalSettings.php

$wgMiserMode = true;

Explicitly write your site’s name

Pages like MediaWiki:Aboutsite and MediaWiki:Pagetitle refer to Glitchdata. You should edit these pages and write your site’s name instead of Glitchdata.


Run Jobs Through Cron

MediaWiki maintains a queue wherein it schedules the jobs to be performed on database (e.g. addition of a new page, update changes, deletion of page etc.). $wgJobRunRate variable controls the rate at which jobs from this queue are executed. Ideally, we should execute jobs when there is least traffic (e.g. during night)

By default, this variable is set to 1; which means that one job will be executed on every page requested from your website. If you set it to 0.1, one job will be executed on every 10 page requests.

If real time updates are not important in your website, it is better to set job rate variable to 0 and then setup a cron job to execute all the accumulated jobs in off-peak hours.

To set job rate to zero, add the following in LocalSettings.php

$wgJobRunRate = 0;

Then you can set a crontab like this:

0 0 * * * /usr/bin/php /var/www/wiki/maintenance/runJobs.php > /var/log/runJobs.log 2>&1

This will cause jobs to run in batch mode at midnight on all days.

MySQL Server

  • For a heavy concurrent write load, InnoDB is essential.
    • Set $wgAntiLockFlags = ALF_NO_LINK_LOCK | ALF_NO_BLOCK_LOCK; to reduce lock contention, at the expense of introducing occasional inconsistencies.
  • Use memcached, not the default MySQL-based object cache.

Multiple Servers

  • Split the App server from the DB server.
    • This improves load
    • May introduce latency.
  • MySQL clusters are possible to reduce DB load.

Links