Manual:Performance tuning

This page provides a quick overview of ways to improve the performance of MediaWiki. Also see Manual:Cache.

Contents [hide] 1	Cache 1.1	Opcode caching 1.2	memcached 1.3	Output caching 1.4	HTTP caching proxies and HTTP acceleration 2	Other web server tuning 3	Configuration settings 4	PHP tuning 4.1	mbstring 4.2	FastStringSearch 4.3	HipHop 5	Database configuration and setup 5.1	MySQL 5.2	Multiple servers 6	Benchmarking 7	See also Cache Opcode caching See Manual:Cache#PHP_caching and PHP_configuration#Opcode_caching Opcode caches store the compiled output of PHP scripts, greatly reducing the amount of time needed to run a script multiple times. Supported opcode caches are APC, eAccelerator (no longer supported since MW1.19), mmTurck, WinCache and XCache; see $wgMainCacheType.

memcached See Memcached The user interface text and other expensive objects can be cached by the opcode user cache or memcached, as will logins and partially completed pages.

If you have enough available RAM, you should use memcached, which will require at least 80MB or more of RAM, about 60MB for code plus whatever you need for cache. If you balance your load across multiple webservers, you should use a dedicated memcached (cluster).

Output caching See Manual:File cache for instructions on enabling and configuring rendered page caching MediaWiki pages can be computationally expensive to render. MediaWiki has an optional file caching system that stores the output of rendered pages. For larger sites, using an external cache like Squid or Varnish is preferable to using the file cache.

HTTP caching proxies and HTTP acceleration See Manual:Squid caching and Manual:Varnish caching Simply put, HTTP accelerators/caching proxies (such as Squid and Varnish) store copies of pages sent out by the web server. When a cached page is requested, the accelerator serves up the copy instead of passing the response on to the web server. This can tremendously reduce the load on the web server. When a page is updated, the copy is removed from the accelerator's cache.

See also this article for instructions on using Apache's mod_disk_cache with MediaWiki.

Other web server tuning SPDY protocol can help, even with ResourceLoader.[1] Configuration settings Large sites running MediaWiki 1.6 or later should set $wgJobRunRate to a low number, say 0.01. See Manual:Job queue for more information.

PHP tuning mbstring Although MediaWiki can work without the mbstring PHP library, it is highly recommended for performance reasons (note: mbstring.func-overload configuration option must be off).

FastStringSearch Can have great impact in some cases, probably never harms.[1]

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 (some brave attempts can be found at HipHop deployment).

Database configuration and setup MySQL 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 The database software and web server software will start to fight over RAM on busy MediaWiki installations that are hosted on a single server. If your wiki has a consistent traffic, a logical step, once other performance optimizations have been made (and cache serves most of the content), is to put the database and web server on separate servers (or, in some cases, multiple separate servers, starting with a slave.) Also:

check that MySQL has query cache enabled and enough memory; give most memory to innodb_buffer_pool; add cores for MySQL if maxed out at peak times; give memcached even more RAM for in-memory cache. Benchmarking Some tools can help quickly evaluate the effects of performance tuning.

http://webpagetest.org is "real life" testing, commanded in your browser. ab is a command line tool which quickly produces some nice stats. PageSpeed profileinfo.php See also Quick harmless solutions Manual:APC, Manual:Cache http://dammit.lt/2007/01/26/mediawiki-performance-tuning/ : APC and a few simple settings that boost performance More extensive changes, sacrificing some functionality User:Aaron Schulz/How to make MediaWiki fast Comprehensive MediaWiki performance optimisation (mostly redundant with this page and what above) User:Ilmari Karonen/Performance tuning, focusing on small wikis Use cases Wikipedia: Site internals, configuration, code examples and management issues [PDF, 2007] Caching, minification, domain-sharing and compression techniques used by WikiFur For developers: Logging and profiling North's Performance chapter ↑ Jump up to: 1.0 1.1 Niklas Laxström, Performance is a feature, December 9th, 2013.