Manuel:Réglage des performances
Cette page fournit un aperçu des différentes manières d'améliorer les performance de MediaWiki.
Contexte
MediaWiki est capable de se redimensionner pour satisfaire les besoins des grandes fermes de wikis telles que celles de la Fondation Wikimedia, WikiHow et Fandom et peut tirer avantage d'un grand nombre de méthodes y compris celle du partage de charge entre plusieurs serveurs de base de données en partage de charge, la mise en cache des objets memcached, les caches Varnish (voir la [[Manuel:Cache Varnish|Mise en case Varnish]]) et les serveurs d'applications multiples. Pour la plupart des petites installations, c'est un peu luxueux - quoique, et activer simplement le cache des objets et optimiser les performances PHP doivent suffire.
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
La plupart des problèmes de cette page ont été rassemblés dans un manifeste puppet (puppet/modules/role/manifests/simple_performant.pp et puppet/modules/role/manifests/simple_miser.pp). Si vous installez Puppet, vous pouvez les appliquer sur votre serveur en une seule commande.
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 la tâche T274041.
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.[1])
Pour installer APCu, utiliser :
sudo apt-get install php-apcu php-igbinary
Le script apc.php est livré avec l'archive APCu et peut être utilisé pour inspecter l'état du cache, mais aussi pour examiner le contenu du cache utilisateurs afin de vérifier que MediaWiki l'utilise correctement.
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 $wgMainCacheType avec une clé dans $wgObjectCaches.
Il existe des interfaces préconfigurées pour Memcached, APC, et MySQL.
Il est possible de configurer des bases arrière supplémentaires via $ObjectCaches (par exemple pour Redis).
// Default:
// $wgMainCacheType = CACHE_NONE;
Serveur web unique
Si APC est installé, nous vous recommandons fortement de l'utiliser en configurant ce qui suit dans LocalSettings.php :
$wgMainCacheType = CACHE_ACCEL;
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.
En initialisant $wgParserCacheType à CACHE_DB, vous rangerez ces clés hors de la base de données.
Si vous utilisez $wgMainCacheType = CACHE_ACCEL; et que les utilisateurs ne peuvent pas se connecter à cause d'erreurs du type session hijacking, essayez de modifier $wgSessionCacheType en CACHE_DB.
Voir la tâche T147161 pour plus d'informations.
Si vous ne pouvez pas utiliser APC, essayez d'installer Memcached (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 :
$wgMainCacheType = CACHE_DB;
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 memcached.
Il est important de ne pas utiliser APC pour le cache principal si vous avez 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 (cache local au serveur), 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 interwiki de la base de données.
Voir Interwiki cache 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 l10n_cache de la base de données. Assurez-vous que $wgCacheDirectory dans LocalSettings.php est initialisé avec un chemin valide pour utiliser un système de cache local. Voir la Mise en cache pour d'autres détails.
Sidebar cache
A small save in DB queries can be obtained by caching the sidebar (disabled by default).
See $wgEnableSidebarCache and $wgSidebarCacheExpiry.
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 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 Manuel:Cache des fichiers 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
- Si vous utilisez Apache comme serveur web, adoptez PHP-FPM et non pas mod_php car PHP-FPM optimises la réutilisation des processus PHP.
- configurer 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. See Manuel:Robots.txt.
- Le protocole HTTP/2 peut vous aider, même avec ResourceLoader.[2]
Paramètres de configuration
Les grands sites qui exécutent MediaWiki 1.6 ou plus récent doivent initialiser $wgJobRunRate avec une valeur basse, disons 0.01. Voir File d’attente des travaux pour plus d'informations.
Composer
MediaWiki utilise composer pour organiser la dépendance des bibliothèques.
Par défaut elles sont incluses à partir du répertoire /vendor en utilisant un chargeur (autoloader) dynamique.
Ce chargeur doit rechercher les répertoires, ce qui peut prendre du temps.
Il est recommandé de générer un chargeur statique avec Composer, afin d'avoir un wiki plus réactif.
L'utilisation d'un chargeur statique est la valeur par défaut pour toutes les installations MediaWiki pour le téchargement des archives ou à partir de Git. Si pour une raison quelconque cela n'est pas le cas, utilisez ceci pour générer un chargeur 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.
Configuration de la base de données
MySQL
En cas d'écritures concurrentes fréquentes, InnoDB est essentiel. Utilisez memcached, et non pas le cache de l'objet par défaut basé sur MySQL.
Voir ci-après pour quelques éléments de configuration de la base de données. Vous pouvez aussi essayer d'exécuter le script mysql-tuning-primer pour obtenir quelques statistiques rapides et des suggestions.
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 quand elles sont hébergées sur un serveur unique. 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 :
- vérifiez que MySQL possède un cache de requêtes activé et suffisamment de mémoire;
- attribuez le plus possible de mémoire à innodb_buffer_pool;
- ajoutez des coeurs à MySQL si vous êtes à court de processeurs aux moments de pointe;
- attribuez même à memcached davantage de RAM pour le cache en mémoire.
Analyse comparative
Certains outils peuvent aider à évaluer rapidement les effets du réglage des performances.
- http://webpagetest.org est le test dans la vie réelle, commandé dans votre navigateur.
- ab est un outil en mode ligne de commande qui produit rapidement certaines statistiques intéressantes.
- PageSpeed
Voir aussi
- http://dammit.lt/2007/01/26/mediawiki-performance-tuning/ : APC et quelques simples paramètres qui décuplent les performances
- Changements plus importants, sacrifiant certaines fonctionnalités
- Comment accélérer MediaWiki
- Optimisation détaillée de la performance de MediaWiki (en grande partie redondant avec cette page et ce qui se trouve ci-dessus)
- User:Ilmari Karonen/Performance tuning, axé sur les petits wikis
- Cas d'utilisation :
- Pour les développeurs :
- Documentation spécifique à WikiMedia :
Références
- ↑ APCu GitHub problème 19: Blocages Apache sur pthread wrlocks
- ↑ Niklas Laxström, La performance est une fonctionnalité, 9 décembre 2013.