Manual:Performance tuning/fr

Cette page fournit un aperçu des différentes manières d'améliorer les performance de MediaWiki.

Contexte
MediaWiki is capable of scaling to meet the needs of large wiki farms such as those of Wikimedia Foundation, WikiHow and Fandom and can take advantage of a wide number of methods including multiple load-balanced database servers, memcached object caching, Varnish caches (see Manual:Varnish caching) and multiple application servers. For most smaller installations, this is overkill though, and simply enabling object caching and optimizing PHP performance should suffice.



Démarrage rapide
Version courte : Nous recommandons le cache bytecode pour PHP, APCu comme cache objet local, Memcached pour le cache principal ; c’est ce que la Fondation Wikimedia utilise pour Wikipedia et autre.

Dans certains cas, la mise en cache excessive à un trop grand nombre de niveaux peut dégrader les performances.



Démarrage rapide avec Puppet
Most of the tweaks on this page have been collected in a puppet manifest ( and ). If you install Puppet, you can apply them to your server with a single command.

PHP


Mise en cache de bytecode

 * See PHP configuration

PHP works by compiling a PHP file into bytecode and then executing that bytecode. Le processus consistant à compiler une grosse application telle que Mediawiki prend énormément de temps. Les accélérateurs PHP fonctionnent en stockant le bytecode compilé et en l'exécutant directement, supprimant ainsi le temps de compilation.

OPcache is included in PHP 5.5.0 and later and is the recommended accelerator for MediaWiki. Autre caches d'opcode pris en charge : WinCache.

Les caches Opcode stockent la sortie compilée des scripts PHP, ce qui réduit de beaucoup le temps nécessaire à leur excution quand ils sont appelés plusieurs fois. Il n'est pas nécessaire de configurer MediaWiki pour utiliser le bytecode PHP avec le cache et cela fonctionne simplement une fois l'installation et l'activation réalisées.

Depuis MediaWiki 1.36, il peut être plus lent sur les systèmes qui ne disposent pas de mise en cache de l'opcode. Voir.



Mise en cache des objets
For more information about local server, main cache and other cache interfaces, see Manual:Caching.



Serveur local
Cette interface est utilisée pour des mises en cache légères directement sur le serveur web. Cette interface garde de manière persistente, les valeurs stockées au fil des requêtes web.

La présence d'une base arrière prise en charge est automatiqueent détectée par MediaWiki. Il n'est pas nécessaire de configurer MediaWiki.

For PHP 7+, you should install APCu or WinCache. (On PHP 5, APCu was known to be unstable in some cases. )

Pour installer APCu, utiliser :

A script,  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.



Cache principal
Cette interface est utilisée comme cache objet principal pour les objets plus grands.

Le cache principal est désactivé par défaut et doit être configuré manuellement. To enable it, set to a key in. Il existe des interfaces préconfigurées pour Memcached, APC, et MySQL. Il est possible de configurer des bases arrière supplémentaires via (par exemple pour Redis).



Serveur web unique
If you have APC installed is strongly recommended to use that by setting the following in :

Une fois configuré, le cache de sortie du magasin de session utilisateur et de l’analyseur héritera également de ce paramètre MainCacheType.

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 to CACHE_DB, which will move those keys out to the database instead.

If using  and users are unable to login due to "session hijacking" errors, consider overriding  to. See task T147161 for more info.

If you can't use APC, consider installing (requires at least 80MB of RAM). L'installation de Memcached est beaucoup plus compliquée mais il est plus efficace.

Si ni APC ni Memcached n’est une option, vous pouvez effectuer un repli pour stocker le cache objet dans votre base de données. Le préréglage suivant permet de le faire:



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

It is important that you do not use APC as your main cache if you have multiple web servers. Ce cache doit être coordonné de manière centralisée pour une installation MediaWiki donnée. 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.



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



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



Mise en cache des pages affichées
Page view caching increases performance tremendously for anonymous (not logged-in) users. It does not affect performance for logged-in users.



Proxy de mise en cache
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.

Exemples de proxy cache:
 * Varnish Cache, this is currently (as of November 2018) used by Wikipedia. See also Manual:Varnish caching.
 * Squid, ceci a été utilisé par Wikipedia avant 2012.
 * Apache's mod_cache_disk, see this article for instructions with MediaWiki.



Cache des fichiers

 * See 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.



Serveur web

 * 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. Ceci réduit généralement la charge du serveur.
 * HTTP/2 protocol can help, even with ResourceLoader.



Paramètres de configuration
Large sites running MediaWiki 1.6 or later should set to a low number, say 0.01. See for more information.

Composer
MediaWiki uses composer for organizing library dependencies. By default these are included from the  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. Si pour une raison quelconque cela n'est pas le cas, utilisez ceci pour générer un autoloader statique :

composer update -o --no-dev

N’oubliez pas que ceci devra être relancé après chaque mise à jour de MediaWiki car il inclut une copie statique des bibliothèques et des classes existant dans le logiciel.



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.

<span id="Multiple_servers">

Serveurs multiples
Le logiciel de base de données et le logiciel de serveur web commenceront à se battre sur la RAM pour les installations MediaWiki occupées qui sont hébergées sur un seul serveur. Si votre wiki a un trafic cohérent, une étape logique, une fois que d’autres optimisations de performance ont été faites (et que le cache sert la plupart du contenu), est de mettre la base de données et le serveur web sur des serveurs séparés (ou, dans certains cas, plusieurs serveurs séparés, en commençant par une réplique.) Également :


 * 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.

Analyse comparative
Certains outils peuvent aider à évaluer rapidement les effets du réglage des performances.


 * http://webpagetest.org is "real life" testing, commanded in your browser.
 * ab is a command line tool which quickly produces some nice stats.
 * PageSpeed

<span id="See_also">

Voir aussi

 * http://dammit.lt/2007/01/26/mediawiki-performance-tuning/ : APC and a few simple settings that boost performance


 * Des changements plus importants, sacrifiant certaines fonctionnalités
 * 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
 * North's Performance chapter
 * Wikimedia specific documentation:
 * Backend performance guide of the Wikimedia Performance Team
 * Frontend performance guide of the Wikimedia Performance Team