This page provides a quick overview of ways to improve the performance of MediaWiki. Also see Manual:Cache.
Opcode caching[edit | edit source]
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[edit | edit source]
- 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[edit | edit source]
- 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[edit | edit source]
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.
Configuration settings[edit | edit source]
mbstring[edit | edit source]
Database configuration and setup[edit | edit source]
MySQL[edit | edit source]
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[edit | edit source]
The database software and web server software will start to fight over RAM on busy MediaWiki installations that are hosted on a single server. A logical step, once other performance optimizations have been made, is to put the database and web server on separate servers (or, in some cases, multiple separate servers.)
HipHop[edit | edit source]
HipHop is an awesome tool provided by Facebook that takes PHP and does freaky magic to turn it into compilable C++. The resulting binaries are way faster than Zend PHP could ever hope to be. HipHop support isn't complete in MediaWiki, and should not be attempted by the faint hearted.
See Also[edit | edit source]
- User:Aaron Schulz/How to make MediaWiki fast
- User:Ilmari Karonen/Performance tuning, focusing on small wikis
- http://dammit.lt/2007/01/26/mediawiki-performance-tuning/ : also APC and a few simple settings that boost performance
- meta:Wikimedia servers, Wikimedia's caching and multiple server strategy for its sites
- Caching, minification, domain-sharing and compression techniques used by WikiFur
- Wikipedia: Site internals, configuration, code examples and management issues [PDF, 2007]
- User:Robchurch/Performance tuning , mostly about the PHP APC module