Manual:Varnish caching/fr

Varnish est un serveur proxy inverse, efficace et léger qui réduit le temps nécessaire pour distribuer les pages demandées fréquemment.

Varnish est un accélérateur HTTP qui stocke les copies des pages distribuées par le serveur web. La prochaine fois que la même page sera demandée, Varnish va distribuer la copie au lieu de la redemander au serveur Apache. Cette méthode de cache supprime le besoin pour MediaWiki de regénérer la même page à chaque fois, ce qui améliore les performances de manière fulgurente.

Varnish a l'avantage d'être conçu spécialement pour une utilisation comme accélérateur HTTP (proxy inverse). Il socke la plupart de ses données de cache en mémoire, ce qui crée moins de fichiers disque et réduit les accès au système de fichiers par rapport au paquet qui est plus important et multi-fonction. Tout comme Squid, il distribue les pages souvent demandées, aux utilisateurs anonymes (par IP) à partir d'un cache au lieu de les demander au serveur web originel. Ceci réduit à la fois l'utilisation de la CPU et l'accès à la base de données par le serveur MediaWiki de base.

Grâce à cette performance de gain, MediaWiki a été conçu pour s'intégrer avec un cache web et il notifie Squid ou Varnish quand une page doit être purgée du cache afin d'être regénérée.

Du point de vue MediaWiki, une installation de Varnish correctement configurée est interchangeable avec son équivalent Squid.



Architecture
Un exemple de configuration Varnish + Apache + MediaWiki sur un même serveur est donné ci-dessous. Une stratégie de cache un peu plus complexe peut utiliser plusieurs serveurs web derrière les mêmes caches Varnish (tous pouvant être considérés ensemble comme un seul hôte) ou utiliser des serveurs indépendants pour délivrer du countenu wiki ou des images.

Vu de l'extérieur, Varnish se comporte comme un serveur web. En réalité il passe les requêtes au serveur web Apache, mais uniquement lorsque c'est nécessaire. Apache s'exécutant sur le même serveur n'écoute que les requêtes du localhost (127.0.0.1) tandis que Varnish n'écoute que les requêtes arrivant sur l'adresse IP externe du serveur. Les deux services peuvent se partager le port 80 sans entrer en conflit pour autant que chacun d'eux est lié à une adresse IP différente.



Configurer Varnish
La configuration suivante fonctionne pour Varnish version 4 et les suivantes.



Configurer MediaWiki
Comme Varnish fait ses requêtes à partir de localhost, Apache recevra directement  pour l'adresse IP du distant. Néanmoins, comme Varnish redirige les requêtes vers Apache, il est configuré pour ajouter l'entête X-Forwarded-For de sorte à ce que l'adresse du distant extérieur soit préservée. MediaWiki doit être configuré pour utiliser l'entête X-Forwarded-For afin d'afficher correctement les adresses des utilisateurs dans special:recentchanges.

La configuration nécessaire est la même pour Squid que pour Varnish. Assurez-vous que le fichier LocalSettings.php contient les lignes suivantes :

Assurez-vous de remplacer '192.168.0.1' par l'adresse IP sur laquelle votre cache Varnish est à l'écoute. Ces paramètres servent à deux choses :
 * Si une requête est reçue du serveur cache Varnish, les journaux MediaWiki ont besoin d'afficher l'adresse IP de l'utilisateur et non pas celle de Varnish. Une page Special:recentchanges dans laquelle chaque modification est repportée avec '127.0.0.1' est tout sauf utile; le listing qui s'adresse à un serveur Squid ou Varnish demande donc à MediaWiki d'ignorer l'adresse IP et de lire l'entête 'x-forwarded-for' à la place, pour connaitre l'adresse IP de l'utilisateur.
 * Si une page ou une image est modifiée sur le wiki, MediaWiki envoie une notification à chaque serveur listé dans en demandant de supprimer (purger) la page obsolète enregistrée.

Utilisez pour les adresses qui ne doivent pas figurer parmi les modifications récentes, et qui ne reçoivent pas les messages HTTP PURGE. Par exemple, si Apache et Squid sont respectivement sur 127.0.0.1 et une adresse externe sur la même machine, il n'est pas nécessaire d'envoyer un message purge à Apache à l'attention de Squid. De la même façon, si Squid écoute sur plusieurs adresses, n'envoyez le purge que sur l'une d'entre-elles.

Voir aussi les Paramètres de configuration Squid pour tous les paramètres liés à la mise en cache Squid/Varnish.

Si vous utilisez HTTPS, assurez-vous d'initialiser à la même valeur que  mais avec le protocole http://, afin d'empêcher que les requêtes de purge ne soient envoyées en HTTPS, depuis que Varnish ne prend plus en compte HTTPS.

If using, be sure to send request header "X-Forwarded-Proto: https" to suppress the redirect, otherwise disable $wgForceHTTPS to prevent redirect loops.



Quelques notes
Notez que Varnish est une alternative à Squid, et ne remplace pas les autres portions de la stratégie de mise en cache complète de MediaWiki comme :


 * Code PHP précompilé: Le comportement par défaut de PHP sous Apache est de charger et d'interpréter les scripts web PHP à chaque fois que l'on en a besoin. L'installation d'un cache tel que APC (, puis allouez la mémoire en initialisant  ou mieux dans  ) peut réduire de beaucoup le temps d'utilisation de la CPU pour que Apache délivre le contenu PHP.
 * Localisation/Internationalisation: Par défaut, MediaWiki va créer une énorme table de base de données  à laquelle il accède constamment - ce qui va vraisemblablement faire plus que doubler la charge du serveur de base de données après une mise à jour avec la dernière version de MediaWiki. Initialisez  afin de forcer l'enregistrement des informations de localisation à l'intérieur du système de fichiers pour remédier à cela.
 * Variables et données de session: L'enregistrement de données variables telles que la barre latérale MediaWiki, la liste des espaces de noms ou la liste noire anti-abus dans un cache mémoire va accélérer un peu la vitesse d'une installation MediaWiki. Forcer les données de connexion des utilisateurs dans un endroit commun est aussi essentiel à toute installation dans laquelle de multiples serveurs Apache interchangeables sont cachés derrière les mêmes caches Varnish pour fournir les pages des mêmes wikis. Installez le paquet memcached et initialisez les options suivantes dans  pour forcer à la fois les informations de connexion des utilisateurs et les variables en cache à utiliser memcache :
 * Notez que, si vous avez de multiple serveurs, l'adresse 'localhost' doit être remplacée avec celle du ou des serveurs 'memcached' partagés, qui doit être la même pour tous les serveurs web accessibles, de votre site. Cela assure que si un utilisateur se connecte à l'un des serveurs de la grappe, il est connecté au wiki sur tous les serveurs web interchangeables.
 * Notez que, si vous avez de multiple serveurs, l'adresse 'localhost' doit être remplacée avec celle du ou des serveurs 'memcached' partagés, qui doit être la même pour tous les serveurs web accessibles, de votre site. Cela assure que si un utilisateur se connecte à l'un des serveurs de la grappe, il est connecté au wiki sur tous les serveurs web interchangeables.
 * Notez que, si vous avez de multiple serveurs, l'adresse 'localhost' doit être remplacée avec celle du ou des serveurs 'memcached' partagés, qui doit être la même pour tous les serveurs web accessibles, de votre site. Cela assure que si un utilisateur se connecte à l'un des serveurs de la grappe, il est connecté au wiki sur tous les serveurs web interchangeables.

Souvent il existe plusieurs moyens alternatifs pour mettre en cache mais ils conduisent au même résulat. Voir.



Configuration Apache


Fichier journal
Le journal du serveur web Apache, par défaut, n'affiche que l'adresse du serveur cache Varnish, dans cet exemple 127.0.0.1:80

Apache peut être configuré pour journaliser l'adresse de l'utilisateur originel en capturant l'information x-forwarded-for dans un format personnalisé de fichier journal.

Exemple de fichier httpd.conf de Apache pour configurer les traces de x-forwarded-for :



Lien immédiat vers les images
Si un site utilise  de Apache pour bloquer les tentatives des autres sites web aux images immédiates (hotlink), cete configuration devra être supprimée et la configuration équivalente ajoutée dans les fichiers de paramètres de Varnish. Là où un serveur d'images se trouve derrière Varnish, typiquement 90% ou plus des requêtes communes d'images n'arrivent pas jusque Apache et ne seront pas bloquées par un contrôle http_referer dans les configurations Apache.



Voir aussi

 * Varnish in Layman's Terms
 * Varnish in Layman's Terms
 * Varnish in Layman's Terms