Manual:Performance tuning/ko

이 페이지는 미디어위키의 성능을 향상 시킬 수 있는 방법들을 제공합니다.

요점

미디어위키는 Wikimedia Foundation, WikiHow, Fandom과 같이 거대한 규모로 운영되는 위키 팜을 위해 성능적인 요구사항을 충족할 수 있는 다양한 기능을 제공합니다. 이는 다중 로드밸런싱 데이터베이스 서버, memcached 오브젝트 캐싱, Varnish caches (Manual:Varnish caching 참조), 다중 애플리케이션 서버를 포함한 다양한 솔루션을 포함하고 있습니다. 대부분의 소규모 플랫폼에서는 이러한 조치가 과도한 오버스펙일 수 있습니다. 오브젝트 캐싱과 PHP 성능을 최적화하는 정도로도 충분한 경우가 많으니 참고하시기 바랍니다.

빠른 시작

3줄 요약: PHP에는 바이트코드 캐시를, 로컬 오브젝트 캐시에는 APCu를, 메인 캐시로는 Memcached를 사용하는 것을 권장합니다. Wikimedia Foundation에서도 위키피디아를 포함한 플랫폼에 이러한 방식을 사용하고 있습니다.

In some cases, over-caching at too many levels may degrade performance.

퍼핏(Puppet)으로 빠르게 시작하기

Most of the tweaks on this page have been collected in a puppet manifest (puppet/modules/role/manifests/simple_performant.pp and puppet/modules/role/manifests/simple_miser.pp). If you install Puppet, you can apply them to your server with a single command.

PHP

바이트 코드 캐싱

See PHP configuration#Opcode caching.

PHP works by compiling a PHP file into bytecode and then executing that bytecode. The process of compiling a large application such as MediaWiki takes considerable time. PHP accelerators work by storing the compiled bytecode and executing it directly reducing the time spent compiling code.

Opcache is included in PHP 5.5.0 and later and is the recommended accelerator for MediaWiki.

Opcode caches store the compiled output of PHP scripts, greatly reducing the amount of time needed to run a script multiple times. MediaWiki does not need to be configured to do PHP bytecode caching and will "just work" once installed and enabled.

MediaWiki versions 1.36 to 1.38 may be slower on systems without op code caching. See T274041.

객체 캐싱

See also Object cache , for how to use local server and main caching in MediaWiki core or an extension.

웹 서버

This interface is used for lightweight caching directly on the web server. This interface is expected to persist stored values across web requests.

Presence of a supported backend is automatically detected by MediaWiki. No MediaWiki configuration necessary.

For PHP 7+, you should install APCu or WinCache. WinCache is only supported by MediaWiki ≤1.42.

To install APCu, use:

sudo apt-get install php-apcu php-igbinary

A script, apc.php is bundled with the APCu package which can be used to inspect the status of the cache, and also examine the contents of the user cache to verify that MediaWiki is correctly using it.

Main cache

This interface is used as the main object cache for larger objects.

The main cache is disabled by default and needs to be configured manually. To enable it, set $wgMainCacheType to a key in $wgObjectCaches . There are preconfigured interfaces for Memcached and MySQL. You can configure additional backends via $ObjectCaches (e.g. for Redis).

// Default:
// $wgMainCacheType = CACHE_NONE;

Single web server

If you have APC installed is strongly recommended to use that by setting the following in LocalSettings.php:

$wgMainCacheType = CACHE_ACCEL;

Once set, the user session store and parser output cache will also inherit this MainCacheType setting.

When using APC with limited RAM (and no Memcached or other object cache configured), then important objects might be evicted too often due to the size of parser output cache building up. Consider setting $wgParserCacheType to CACHE_DB, which will move those keys out to the database instead.

If using $wgMainCacheType = CACHE_ACCEL; and users are unable to login due to "session hijacking" errors, consider overriding $wgSessionCacheType to CACHE_DB. See task T147161 for more info.

If you can't use APC, consider installing Memcached (requires at least 80MB of RAM). While installing Memcached is considerably more complicated, it is very effective.

If neither APC or Memcached is an option, you can fallback to storing the object cache in your database. The following preset will do that:

$wgMainCacheType = CACHE_DB;

Multiple web servers

If your MediaWiki site is served by multiple web servers, you should use a central Memcached server. Detailed instructions are on the memcached page.

It is important that you do not use APC as your main cache if you have multiple web servers. This cache must be coordinated centrally for a single MediaWiki installation. Having each web server use APC as its own MainCache will cause stale values, corruption or other unexpected side-effects. Note that for values that are safe to store in uncoordinated fashion (the "local-server cache"), MediaWiki automatically makes use of APC regardless of this configuration setting.

Interwiki cache

MediaWiki interwiki prefixes are stored in the interwiki database table. See Interwiki cache for how to enable caching.

Localisation cache

By default, interface message translations are cached in the l10n_cache database table. Ensure $wgCacheDirectory in LocalSettings.php is set to a valid path to use a local caching instead. See Help:System message#Caching for more details.

A small save in DB queries can be obtained by caching the sidebar (disabled by default). See $wgEnableSidebarCache and $wgSidebarCacheExpiry.

Page view caching

Page view caching increases performance tremendously for anonymous (not logged-in) users. It does not affect performance for logged-in users.

Caching proxy

A caching proxy (or "HTTP accelerator") stores a copy of web pages generated by your web server. When such page is requested a second time, then the proxy serves up its local copy, instead of passing the request onto the real web server.

This massively improves the response times for page loads by end users, and also tremendously reduces the computational load on the MediaWiki web server. When a page is edited, MediaWiki can automatically purge the local copy from the cache proxy.

Examples of cache proxies:

File cache

See Manual:File cache for main article about this.

In absence of a caching proxy or HTTP accelerator, MediaWiki can optionally use the file system to store the output of rendered pages. For larger sites, using an external cache like Varnish is preferable to using the file cache.

Web server

  • if you use Apache as web server, use PHP-FPM, not mod_php. PHP-FPM optimizes re-use of PHP processes.
    • switch Apache to use the event MPM instead of the prefork MPM.
  • adjust robots.txt to disallow bots from crawling history pages. This decreases general server load. See Manual:robots.txt.
  • HTTP/2 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 매뉴얼:작업 큐 for more information.

Composer

This will provide no benefit if you enable opcache in PHP.

MediaWiki uses composer for organizing library dependencies. By default these are included from the /vendor directory using a dynamic autoloader. This autoloader needs to search directories which can be slow. It is recommended to generate a static autoloader with Composer, which will make your wiki respond faster.

Using a static autoloader is the default for all MediaWiki installations from the tarball download or from Git. If for some reason this is not the case, use the following to generate the static autoloader:

composer update -o --no-dev

Remember that this will need to be re-run after each MediaWiki update as it includes a static copy of which libraries and classes exist in the software.

Database configuration

MySQL

For a heavy concurrent write load, InnoDB is essential. Use memcached, not the default MySQL-based object cache.

See below for some DB configuration tricks. You can also try and run the mysql-tuning-primer script to get some quick statistics and suggestions.

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 replica.) Also:

Benchmarking

Some tools can help quickly evaluate the effects of performance tuning.

See also


References

  1. ↑ Niklas Laxström, Performance is a feature, December 9th, 2013.
Category:MediaWiki development/ko Category:Performance tuning/ko
Category:MediaWiki development/ko Category:Performance tuning/ko