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 de bytecode pour PHP, APCu comme objet cache local, Memcached pour le cache principal; c’est ce que la Fondation Wikimedia utilise pour Wikipedia et autres.

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 du bytecode

 * Voir la Mise en cache d'opcode en PHP.

PHP fonctionne en compilant un fichier PHP en bytecode puis en exécutant ce 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 est inclus dans PHP 5.5.0 et suivants et c'est l'accélérateur recommandé pour 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
Pour d'autres informations concernant le serveur local le cache principal et les autres interfaces de cache, voir la Mise en cache du manuel.



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 automatiquement détectée par MediaWiki. Il n'est pas nécessaire de configurer MediaWiki.

Pour PHP 7+, vous devez installer APCu ou WinCache. (Avec PHP 5, il est connu que APCu peut présenter certaines instabilités. )

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

Le cache principal est désactivé par défaut et doit être configuré manuellement. Pour l'activer, initialisez avec une clé dans. 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.

Lorsque vous utilisez APC avec une RAM limitée (et sans Memcached ni autre objet de cache configuré), alors les objets dont la taille est trop importante peuvent être laissés de côté trop souvent à cause de la taille de la construction du cache de la sortie de l'analyseur syntaxique. Consider setting to CACHE_DB, which will move those keys out to the database instead.

Si vous utilisez  et que les utilisateurs ne peuvent pas se connecter à cause d'erreurs du type session hijacking, essayez de modifier  en. Voir la tâche T147161 pour plus d'informations.

Si vous ne pouvez pas utiliser APC, essayez d'installer  (nécessite au moins 80Mo de RAM). L'installation de Memcached est beaucoup plus compliquée mais il est plus efficace.

Si l'option est ni APC ni Memcached, 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
Si votre site MediaWiki est produit par de multiples serveurs web, alors vous devez utiliser un serveur Memcached centralisé. Les instructions détaillées se trouvent sur la page .

Il est important de ne pas utiliser APC pour le cache principal si vous avec plusieurs serveurs web. Ce cache doit être coordonné de manière centralisée pour une installation MediaWiki donnée. Si chacun des serveurs web utilise APC pour son propre MainCache, vous aurez des valeurs périmées, corrompues ou observerez d'autres effets de bord inattendus. Notez que pour les valeurs pouvant être enregistrées de manière non coordonnée (local-server cache), MediaWiki utilise automatiquement APC quelque soit le paramètre de configuration.



Cache Interwiki
Les préfixes interwiki de MediaWiki sont stockés dans la table  de la base de données. Voir pour la manière d'activer la mise en cache.



Cache des traductions
Par défaut, les traductions des messages d'interface sont mises en cache dans la table de la base de données. Assurez-vous que dans  est initialisé avec un chemin valide pour utiliser un système de cache local. Voir la Mise en cache pour d'autres détails.



Mise en cache des pages affichées
La mise en cache de l'affichage des pages améliore incroyablement les performances pour les utilisateurs anonymes (non-connectés). Cela n'impacte pas les performances pour les utilisateurs déjà connectés.



Proxy de mise en cache
Un proxy de cache (accélérateur HTTP) enregistre une copie des pages web générées par votre serveur web. Si une telle page est demandée à nouveau, alors le proxy renvoie sa copie locale au lieu de transmettre réellement la requête au serveur web.

Ceci accélère beaucoup le temps de réponse pour le chargement des pages par les utilisateurs finaux, et réduit grandement la charge de calcul du serveur web MediaWiki. Lorsqu'une page est modifiée, MediaWiki peut purger automatiquement la copie locale du proxy du cache.

Exemples de proxy de cache :
 * Cache Varnish : actuellement (novembre 2018) utilisé par Wikipedia. Voir aussi la Mise en cache de Varnish.
 * Squid, utilisé par Wikipedia avant 2012.
 * mod_cache_disk de Apache, voir cet article pour les instructions avec MediaWiki.



Cache des fichiers

 * Voir pour l'article principal à ce sujet.

En l'absence d'un proxy de cache ou d'accélérateur HTTP, MediaWiki peut éventuellement utiliser le système de fichiers pour stocker la sortie des pages générées. Pour des sites plus conséquents, il vaut mieux utiliser un cache externe tel que Varnish plutôt que le cache des fichiers.



Serveur web

 * if you use Apache as web server, use PHP-FPM, not mod_php. PHP-FPM optimizes re-use of PHP processes.
 * configure Apache pour utiliser l'événement MPM au lieu du prefork MPM.
 * mettre à jour robots.txt pour empêcher les robots d'explorer les pages d'historique. 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. Cet autoloader doit rechercher les répertoires, ce qui peut prendre du temps. Il est recommandé de générer un autoloader statique avec Composer, afin d'avoir un wiki plus réactif.

L'utilisation d'un autoloader statique est la valeur par défaut pour toutes les installations MediaWiki pour le téchargement de l'archive ou à partir de 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 contient 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 du serveur web commenceront à rivaliser pour la RAM sur les installations actives MediaWiki hébergées sur un unique serveur. Si votre wiki a un trafic cohérent, une étape logique, une fois que les autres optimisations de performance ont été faites (et que le cache dessert 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, sur 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