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 conflict 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.
 * If a page or image is changed on the wiki, MediaWiki will send notification to every server listed in telling it to discard (purge) the outdated stored page.

Use for addresses which need to be kept out of recentchanges, but which do not receive HTTP PURGE messages. For instance, if Apache and Squid are respectively on 127.0.0.1 and an external address on the same machine, there's no need to send Apache a "purge" message intended for Squid. Likewise, if Squid is listening to multiple addresses, only send "purge" to one of them.

See also Squid configuration settings for all settings related to Squid/Varnish caching.

If you use HTTPS, be sure to set to the same value as  but with http:// protocol, to prevent purge requests from being sent as HTTPS, since varnish doesn't support HTTPS.



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é: The default behaviour of PHP under Apache is to load and interpret PHP web scripts each time they are accessed. Installation of a cache such as APC (, then allocate memory by setting  or better in  ) can greatly reduce the amount of CPU time required by Apache to serve PHP content.
 * Localisation/Internationalisation: By default, MediaWiki will create a huge  database table and access it constantly - possibly more than doubling the load on the database server after an "upgrade" to the latest MediaWiki version. Set  to force the localisation information to be stored to the file system to remedy this.
 * Variables et données de session: Storing variable data such as the MediaWiki sidebar, the list of namespaces or the spam blacklist to a memory cache will substantially increase the speed of a MediaWiki installation. Forcing user login data to be stored in a common location is also essential to any installation in which multiple, interchangeable Apache servers are hidden behind the same Varnish caches to serve pages for the same wikis. Install the memcached package and set the following options in to force both user login information and cached variables to use memcache:
 * Note that, if you have multiple servers, the localhost address needs to be replaced with that of the shared memcached server(s), which must be the same for all of the matching web servers at your site. This ensures that logging a user into one server in the cluster logs them into the wiki on all the interchangeable web servers.
 * Note that, if you have multiple servers, the localhost address needs to be replaced with that of the shared memcached server(s), which must be the same for all of the matching web servers at your site. This ensures that logging a user into one server in the cluster logs them into the wiki on all the interchangeable web servers.
 * Note that, if you have multiple servers, the localhost address needs to be replaced with that of the shared memcached server(s), which must be the same for all of the matching web servers at your site. This ensures that logging a user into one server in the cluster logs them into the wiki on all the interchangeable web servers.
 * Note that, if you have multiple servers, the localhost address needs to be replaced with that of the shared memcached server(s), which must be the same for all of the matching web servers at your site. This ensures that logging a user into one server in the cluster logs them into the wiki on all the interchangeable web servers.

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



Configuration Apache


Fichier journal
The Apache web server log, by default, shows only the address of the Varnish cache server, in this example "127.0.0.1:80"

Apache may be configured to log the original user's address by capturing "x-forwarded-for" information under a custom log file format.

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



Lien immédiat vers les images
If a site uses Apache's  to block attempts by other websites to hotlink images, this configuration will need to be removed and equivalent configuration added to Varnish's configuration files. Where an image server is located behind Varnish, typically 90% or more of common image requests never reach Apache and therefore will not be blocked by a "http_referer" check in Apache's configurations.



Voir aussi

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