Jump to content

메뉴얼:성능 향상

From mediawiki.org
This page is a translated version of the page Manual:Performance tuning and the translation is 7% complete.
Languages:

이 페이지는 미디어위키 설치의 성능을 향상시키는 방법을설명합니다.

미디어위키는 Wikimedia Foundation, WikiHow, Fandom과 같이 거대한 규모로 운영되는 위키 팜을 위해 성능적인 요구사항을 충족할 수 있는 다양한 기능을 제공합니다. 이는 다중 로드밸런싱 데이터베이스 서버, memcached 오브젝트 캐싱, Varnish caches (Manual:Varnish caching 참조), 다중 애플리케이션 서버를 포함한 다양한 솔루션을 포함하고 있습니다.

대부분의 소규모 플랫폼에서는 이 페이지에 있는 조치를 모두 하는 것이 오버스펙일 수 있습니다. Start with making sure you have PHP OPcache enabled, PHP APCu installed , and enable the "main cache" in MediaWiki.

빠른 시작

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

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

If you happen to manage your server with Puppet, you can apply some of these tips automatically. 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).

PHP

바이트 코드 캐싱

OPcache improves MediaWiki performance by removing the need for PHP to load and compile scripts on every request.
같이 보기: PHP configuration#Opcode caching

PHP works by compiling a PHP files to bytecode, and then executing that bytecode. When compiling a large application such as MediaWiki, this takes time. OPcache works by reusing previously compiled bytecode, and executing it directly. This avoids spending time to compile the same code on every request. OPcache was introduced in PHP 5.5.0 (Compatibility § PHP).

There is no MediaWiki configuration required to use OPcache. Once PHP OPcache is installed and enabled on your server, it "just works".

LuaSandbox

If you use 확장기능:Scribunto , be sure to install LuaSandbox , which is faster than the default LuaStandalone engine.

객체 캐싱

For how to use caching as a developer in MediaWiki core or an extension, see Object cache .

웹 서버

The local server cache is used for lightweight caching directly on the web server.

To enable it, install PHP APCu. Prior to MediaWiki 1.42, WinCache was supported as well.

Once installed, MediaWiki automatically detects and uses the local server cache. No MediaWiki configuration necessary.

To install APCu on Debian and its derivatives, 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

The main cache can be used by MediaWiki to reuse results of larger or more expensive computations.

Main cache (recommended)

The main cache is disabled by default. To enable it, follow instructions from the Memcached or Redis page.

Alternatively, you can define custom backends via $wgObjectCaches and set $wgMainCacheType to a key in $wgObjectCaches.

If your MediaWiki installation is served from multiple web servers, then your web servers must refer to the same cache server(s). You must not use APCu as your main cache if you have multiple web servers. Having each web server use its own separate main cache would cause stale values, corruption, and other unexpected side-effects. Note that for lightweight values (the "local server cache"), MediaWiki will still automatically and correctly use of APCu regardless of any $wgMainCacheType setting.

Main cache (basic)

If you operate a small wiki from a single web server and prefer not to install an external service like Memcached or Redis, and you do have APCu installed, then you can APCu as your main cache as well by setting the following in LocalSettings.php . By default, the user session store ($wgSessionCacheType ) and parser output cache ($wgParserCacheType ) inherit the MainCacheType. When using APCu as your main cache, it is recommended to override these in favor of the database. See task T147161 for more info. 

$wgMainCacheType = CACHE_ACCEL;
$wgSessionCacheType = CACHE_DB;
$wgParserCacheType = CACHE_DB;

While installing Memcached is more complicated, it is very effective and recommended.

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.

Limiting requests

One common performance issue is allowing too much concurrency in the webserver. If this happens, various PHP threads can become starved for resources and make no progress. Even worse, they can begin to pile up and not complete even after the user has given up on the page loading causing everything to slow to a crawl. Sometimes its better to do a small number of requests at a time making the other requests wait instead of doing all the requests concurrently.

  • Set PHP's memory_limit to an appropriate value (256MB is a common choice)
  • Calculate how much RAM you can dedicate to PHP processes. Divide that by the memory_limit for PHP. That is the most web server/php threads you should have running at one time. Keep in mind if you have other things running on the same server such as MySQL or Elasticsearch, they also need RAM.
  • Configure your webserver to only allow that many threads. If using Varnish you can use .max_connections, .wait_limit and .wait_timeout to control the number of concurrent backend requests. If using Apache without Varnish, set MaxRequestWorkers
    • If using Varnish you can setup multiple backends with different max connections to prioritize different types of users.
  • Install Excimer and set $wgRequestTimeLimit to a reasonable value (e.g. 300). This will ensure that MediaWiki terminates the request if it gets stuck.
  • If using MariaDB and only using the server for MediaWiki, consider setting max_statement_time in your server .ini file to a value of about 200. This will force any DB query from taking more than 200 seconds. Just remember to remove it before running Update.php .

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.
Retrieved from "https://www.mediawiki.org/w/index.php?title=Manual:Performance_tuning/ko&oldid=8507425"