introduction
Contexte
-
Drupal * est l’un des systèmes de gestion de contenu open source les plus populaires.
Puisqu’il utilise une base de données sous-jacente pour stocker et récupérer des données telles que des pages de contenu, des éléments d’actualités, des commentaires et des articles de blog, Drupal a besoin de beaucoup de puissance de traitement pour afficher une seule page. Chaque impression de page implique le lancement de l’interpréteur PHP, le traitement de tous les éléments Drupal, l’accès à la base de données pour obtenir les informations, la préparation de la présentation visuelle et la fourniture du contenu prêt à l’utilisateur.
Ce processus intensif rend difficile la gestion d’un nombre croissant de personnes consultant le site Web simultanément. Étant donné que chaque visiteur a besoin d’une puissance de traitement non négligeable, les ressources de votre serveur peuvent rapidement devenir un goulot d’étranglement.
Il existe de nombreuses façons d’adapter la croissance et de faire face aux problèmes de performances, dont la plupart peuvent être considérées comme une méthode de mise à l’échelle. La mise à l’échelle en termes de logiciel est considérée comme la capacité du système à supporter une charge accrue, comme un nombre accru de visiteurs simultanés.
-
Varnish * aide à la mise à l’échelle logicielle en ajoutant des logiciels supplémentaires pouvant aider à éliminer les goulots d’étranglement.
Cet article a été testé sur * Ubuntu 14.04 * mais devrait fonctionner avec des modifications de chemin mineures sur * Debian 7 *. Cela peut également fonctionner sur d’autres distributions avec des modifications mineures.
Cache vernis
-
Varnish * est un cache, ce qui signifie que son rôle est de stocker et de rappeler ce qu’une application Web sert à l’utilisateur lors du premier accès au contenu. Ensuite, il peut servir le même contenu * à nouveau * pour les demandes suivantes sans demander à nouveau l’application Web.
Il peut être utilisé pour diffuser du contenu statique, tel que des images, des scripts ou des feuilles de style, car Varnish est extrêmement rapide et gère le trafic beaucoup mieux que * Apache *. Il peut également être utilisé pour mettre en cache le contenu quasi-static; c’est-à-dire un contenu généré dynamiquement par l’application (à l’aide de la base de données et prenant beaucoup de temps à préparer), mais qui reste inchangé pendant un certain temps, rendant le contenu apte à être mis en cache.
Par exemple, lorsqu’un article du site Web est publié, il est rarement mis à jour. Il est alors totalement inutile de faire appel à tous les éléments de traitement de Drupal pour calculer et afficher le même article à chaque fois qu’il est demandé. Varnish se souviendra de servir la même page sans contacter Drupal du tout. Cela permet à Varnish de servir facilement le même contenu à 10, 100, voire 1 000 personnes à la fois - car le traitement d’une page en cache nécessite très peu de puissance de traitement.
Dans la plupart des scénarios, l’utilisation de * Varnish * accélère considérablement la plupart des sites Web. Cela facilite également la gestion des pics d’intérêt soudains (par exemple, lorsqu’un article très populaire est publié). Tout cela se traduit par des visiteurs plus heureux qui reçoivent leur contenu plus rapidement et de manière plus fiable.
Étape 1 - Reconfigurer Apache
Par défaut, * Apache * écoute sur le port 80. Cela permet à Apache de gérer les requêtes Web, comme une requête d’URL de navigateur pour * http: //example.com*. Pour utiliser * Varnish *, il doit pouvoir gérer ces demandes à la place. Nous devons d’abord dire à Apache de ne plus gérer les requêtes sur le port 80.
Changer le port Apache écoute sur
Le port sur lequel * Apache * écoute par défaut est défini dans un fichier appelé * Debian * et * Ubuntu * situé dans + / etc / apache2 +.
Editez le fichier:
sudo nano /etc/apache2/ports.confCela exécutera un éditeur de texte * nano * affichant le contenu par défaut de ce fichier, qui devrait être similaire à celui-ci. Mettez à jour le + NameVirtualHost + et les lignes pour utiliser le port * 81 *:
# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default
# This is also true if you have upgraded from before 2.2.9-3 (i.e. from
# Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and
# README.Debian.gz
NameVirtualHost *:
Listen
<IfModule mod_ssl.c>
# If you add NameVirtualHost *:443 here, you will also have to change
# the VirtualHost statement in /etc/apache2/sites-available/default-ssl
# to <VirtualHost *:443>
# Server Name Indication for SSL named virtual hosts is currently not
# supported by MSIE on Windows XP.
Listen 443
</IfModule>Sauvegardons le fichier en appuyant sur * CTRL + x *, puis * y *, puis * Entrée *.
Changer le port de l’hôte virtuel
Par défaut, une nouvelle installation * Apache * a un hôte virtuel spécifié dans un fichier de configuration situé dans + / etc / apache2 / sites-enabled / 000-default +. Si vous avez plusieurs hôtes virtuels configurés, vous devrez en modifier * tous *.
Pour modifier la configuration de l’hôte virtuel Apache par défaut, tapez:
sudo nano /etc/apache2/sites-enabled/000-default.confLe contenu du fichier commence par les lignes suivantes:
<VirtualHost *:80>
ServerAdmin webmaster@localhostComme avant, nous devons changer le nombre de * 80 * à * 81 *:
<VirtualHost *:>
ServerAdmin webmaster@localhostEnregistrez le fichier en utilisant * CTRL-x * suivi de * y * et * Entrée *.
Recharger la configuration Apache
Après ces modifications, la configuration Apache doit être rechargée:
sudo service apache2 reloadApache acceptera maintenant les demandes entrantes sur le nouveau port * 81 * et non plus sur * 80 * comme auparavant.
Nous pouvons le confirmer en ouvrant notre site Web dans le navigateur. Il ne devrait pas s’ouvrir sans spécifier le port (comme * http: //example.com*) mais s’afficher correctement après avoir ajouté le nouveau port à l’adresse (comme * http: / /exemple.com:81*).
Nous sommes maintenant prêts à installer et à configurer * Varnish * pour nous aider à rendre le site plus rapide.
Étape 2 - Installation de vernis
Debian et Ubuntu ont tous les deux des paquets système avec * Varnish *, mais nous vous recommandons d’utiliser des paquets préconfigurés créés par les auteurs de Varnish. Cela garantira que Varnish est à jour, ce qui ne sera pas le cas pour les paquets système.
Tout d’abord, assurez-vous que le paquet * apt-transport-https * est installé, ce qui permet au système d’installer des paquets via une connexion sécurisée:
sudo apt-get install apt-transport-httpsCela installera le paquet nécessaire ou nous dira qu’il a déjà été installé.
La clé publique du serveur de packages Varnish doit être installée afin de vérifier l’authenticité des packages installés. Commencez par basculer sur * root *:
sudo suAjouter la clé:
curl https://repo.varnish-cache.org/ubuntu/GPG-key.txt | apt-key add -Pour * Debian *:
echo "deb https://repo.varnish-cache.org/debian/ wheezy varnish-4.0" >> /etc/apt/sources.list.d/varnish-cache.listPour * Ubuntu *:
echo "deb https://repo.varnish-cache.org/ubuntu/ trusty varnish-4.0" >> /etc/apt/sources.list.d/varnish-cache.list-
Vous pouvez maintenant revenir à votre utilisateur sudo. *
Mettez à jour votre système:
sudo apt-get updateInstaller le vernis:
sudo apt-get install varnishCela installe et exécute Varnish!
Étape 3 - Confectionner du vernis sur le port 80
Par défaut, Varnish écoute sur le port * 6081 *. À la place, nous ferons écouter Varnish sur le port * 80 *, en prenant en compte toutes les demandes entrantes de nos utilisateurs Web, comme * Apache * le faisait auparavant.
Ouvrons le fichier de configuration Varnish en utilisant:
sudo nano /etc/default/varnishRecherchez la section non commentée illustrée ci-dessous:
. . .
## Alternative 2, Configuration with VCL
#
# Listen on port 6081, administration on localhost:6082, and forward to
# one content server selected by the vcl file, based on the request.
# Use a 256MB memory based cache.
#
DAEMON_OPTS="-a :6081 \
-T localhost:6082 \
-f /etc/varnish/default.vcl \
-S /etc/varnish/secret \
-s malloc,256m"
. . .Mettez à jour la ligne pour utiliser le port * 80 * (n’oubliez pas de conserver également le + \ +):
. . .
DAEMON_OPTS="-a : \
-T localhost:6082 \
-f /etc/varnish/default.vcl \
-S /etc/varnish/secret \
-s malloc,256m"
. . .Enregistrez le fichier en utilisant * CTRL-x * et * y * suivi de * Entrée *.
Redémarrez * Varnish * pour que les modifications prennent effet:
sudo service varnish restartNous devrions voir des messages comme ceux-ci sans erreurs:
[ ok ] Stopping HTTP accelerator: varnishd.
[ ok ] Starting HTTP accelerator: varnishd.Maintenant, vérifiez votre site Web dans le navigateur. Au lieu de votre site Drupal qui était auparavant disponible, vous verrez une page blanche avec un message d’erreur disant:
Error 503 Backend fetch failed
Backend fetch failed
Guru Meditation:
XID: 131081
Varnish cache serverCela signifie que Varnish a été correctement configuré pour accepter les connexions entrantes, mais n’est pas encore disponible pour desservir notre site Drupal. Nous allons modifier la configuration pour remettre l’ancien site Drupal en ligne dans les étapes suivantes.
Comment fonctionne le vernis
Une excellente ressource pour acquérir une solide compréhension de * Varnish * est le Varnish Book officiel, mais nous allons aborder quelques faits de base sur la * Le vernis * fonctionne ici.
Vous pouvez également passer à l’étape suivante si vous souhaitez terminer l’installation maintenant et en apprendre davantage plus tard. Cependant, si vous découvrez le fonctionnement de Varnish, vous comprendrez mieux les prochaines étapes.
Langage VCL
La configuration de Varnish est écrite dans un langage appelé * VCL * (Varnish Configuration Language). C’est un langage de programmation simple qui est compilé en code * C * natif par Varnish lui-même.
La configuration est composée de méthodes qui sont exécutées à différents moments du traitement des demandes Web entrantes, ainsi que du reste du contenu de la configuration.
Certaines instructions sont exécutées par Varnish lorsqu’il reçoit la demande du navigateur, mais avant que celle-ci ne soit traitée, lui indiquant si elle doit transférer la demande à l’application réelle ou si elle doit servir le contenu mis en cache. Dans ces instructions, il est possible de manipuler la demande entrante, de modifier son contenu ou de prendre des décisions en fonction de la demande (l’URL, le nom du fichier, les en-têtes ou les cookies).
D’autres instructions sont exécutées lorsque Varnish décide de récupérer le contenu de l’application réelle (dans notre cas, le site Web Drupal). Ces instructions peuvent être utilisées pour manipuler le contenu reçu de l’application.
Encore d’autres instructions sont exécutées lorsque Varnish sert le contenu mis en cache sans le récupérer depuis l’application.
En utilisant * VCL *, il est possible de construire une logique complexe prenant différentes décisions de mise en cache en fonction de nombreux facteurs. Il est également possible de créer un ensemble d’instructions très simple.
Varnish est livré avec une implémentation par défaut raisonnable pour * toutes * ses méthodes, qui peuvent être modifiées si nécessaire. Cela signifie qu’il est possible de spécifier dans la configuration uniquement * certaines * méthodes, et même dans ce cas, seulement * certaines * instructions, en s’appuyant toujours sur les valeurs par défaut pour le reste. Cela facilite l’utilisation des compétences de base de Varnish, tout en permettant de créer des configurations très complexes à mesure que vous ajoutez des instructions personnalisées.
Qu’est-ce qui est mis en cache et qu’est-ce qui ne l’est pas?
La chose la plus difficile à propos de la configuration de Varnish ou de tout autre mécanisme de mise en cache est de décider * quand * et * quoi * mettre en cache. La plupart des problèmes proviennent de décisions incorrectes - en mettant en cache trop ou pas assez.
Avec une installation Drupal typique, cela peut conduire à deux scénarios de problèmes différents.
Le premier est lorsque trop peu de pages sont mises en cache, ce qui rend Varnish presque inutile. Cela n’accélère pas du tout les choses, car la plupart des pages sont extraites directement à partir de l’application Drupal à chaque fois. Cela n’aide en rien les problèmes de performances, mais cela ne casse rien non plus.
La seconde est lorsque trop de pages sont mises en cache. Dans ce cas, il peut s’avérer impossible de se connecter au panneau d’administration. Les visiteurs peuvent obtenir du contenu ancien, non valide ou même du contenu mélangé lorsqu’un contenu différent est fourni à des utilisateurs anonymes et connectés. Dans ce scénario, il est possible de casser des choses qui ont bien fonctionné sans Varnish.
Voyons quelques facteurs communs pour nous aider à décider si * Varnish * mettra ou non le contenu en cache.
Le vernis cache tout
Par défaut, le principe de base est que Varnish met en cache * tout *. La mise en cache dans Varnish est exclusive, pas inclusive, ce qui signifie que tout est mis en cache, sauf indication contraire de votre part.
Méthode de demande
La méthode de requête est la définition de base d’une requête. Vernir par défaut ne met en cache que * les * requêtes GET et HEAD, * ne * met jamais les autres en cache, comme POST, PUT et DELETE. Cela garantit que les demandes destinées à modifier certaines données parviennent intactes à l’application sans être mises en cache.
Autorisation
Par défaut, les demandes de pages protégées par mot de passe ne sont pas du tout mises en cache. * Ceci est vrai uniquement pour les pages protégées avec l’autorisation HTTP Basic *. Varnish n’a pas connaissance des mécanismes spécifiques à l’application, tels que les pages de connexion Drupal. Nous devrons ajouter nos propres règles pour nous assurer que les pages de connexion ne sont pas mises en cache.
En-têtes de cache
Parfois, les applications Web renvoient leurs propres informations de mise en cache dans les en-têtes. Varnish prend en compte ces en-têtes. Ainsi, lorsqu’une application Web telle que Drupal dit à Varnish de ne jamais mettre en cache sa réponse, c’est exactement ce qui se passera à moins de programmer un autre comportement dans le fichier * VCL *. Étant donné que Drupal envoie ses propres informations de mise en cache, ces informations deviendront importantes par la suite.
Biscuits
Les cookies sont peut-être la partie la plus importante et la plus difficile des décisions de mise en cache avec des applications Web.
Par défaut, si des cookies de requête * ou * sont définis, la page ne sera * pas * mise en cache. C’est une décision judicieuse, car, par exemple, les utilisateurs connectés sont identifiés par un cookie de session. Si les pages avec des cookies étaient mises en cache, tous les utilisateurs connectés obtiendraient le même contenu et l’application ne pourrait pas discerner entre les utilisateurs. C’est aussi l’une des plus grandes sources de problèmes, car les cookies sont très répandus. Il arrive souvent que des requêtes contiennent des cookies inoffensifs, tels que des jetons * Google Analytics *, qui ne sont pas du tout utilisés par l’application, mais qui rendent également le contenu impossible à mettre en cache. Sans une décision prudente quant aux cookies qui devraient interdire la mise en cache et ceux qui devraient être ignorés, avec les applications Web actuelles, nous ne disposerions presque plus de la mise en cache, car de nombreux cookies circulent.
La plupart des fragments de la configuration spécifique à Drupal pour Varnish se chargeront de la gestion appropriée des cookies pour supprimer les cookies inutiles et permettre la mise en cache, tout en conservant ceux nécessaires pour, par exemple, maintenir la fonctionnalité de la page d’administration.
Étape 4 - Configuration de Varnish pour Drupal
Ayant une compréhension de base du fonctionnement de la mise en cache avec Varnish, nous pouvons configurer Varnish pour qu’il fonctionne avec notre site Drupal.
Ouvrons le fichier de configuration de Varnish VCL:
sudo nano /etc/varnish/default.vclLe contenu par défaut affiche toutes les méthodes Varnish vides, ce qui signifie que les valeurs par défaut sont utilisées.
Nous pouvons ajouter nos propres instructions de configuration pour atteindre la stratégie de mise en cache nécessaire.
Le premier bloc indique à Varnish comment contacter le serveur Web principal, qui dans notre cas est * Apache * avec une installation * Drupal *. Nous allons changer le code pour refléter le port * 81 * que nous avons utilisé pour configurer * Apache *.
. . .
# Default backend definition. Set this to point to your content server.
backend default {
.host = "127.0.0.1";
.port = "";
}
. . .Maintenant, localisez la méthode d’espace réservé vide + vcl_recv +:
. . .
sub vcl_recv {
# Happens before we check if we have this in cache already.
#
# Typically you clean up the request here, removing cookies you don't need,
# rewriting the request, etc.
}
. . .Le code de cette méthode est exécuté before * Varnish * contacte notre site * Drupal *. C’est l’endroit où nous pouvons supprimer certains cookies du navigateur, forcer la mise en cache pour certaines adresses et prendre la première décision de mise en cache. Nous allons ajouter plusieurs règles qui accomplissent les tâches suivantes:
-
Autoriser Varnish à servir du contenu de cache obsolète (ancien) en cas d’échec de Drupal. Le site sera partiellement disponible même si Drupal ne répond pas
-
Assurez-vous qu’aucune page administrative n’est mise en cache, obligeant Varnish à ignorer le cache pour certaines URL.
-
Assurer la mise en cache des fichiers statiques - images, scripts, feuilles de style
-
Supprimez tous les cookies autres que plusieurs cookies nécessaires au fonctionnement de Drupal, y compris les fonctionnalités de connexion de l’utilisateur
Pour ce faire, remplaçons le bloc par défaut par le suivant. Les lignes précédées de * # * sont des commentaires et ne seront pas prises en compte par Varnish, mais sont là pour aider à rendre le fichier de configuration facile à comprendre. Ce bloc entier est nouveau et peut être collé tel quel:
. . .
sub vcl_recv {
# Return (pass) instructs Varnish not to cache the request
# when the condition is met.
## ADMIN PAGES ##
# Here we filter out all URLs containing Drupal administrative sections
if (req.url ~ "^/status\.php$" ||
req.url ~ "^/update\.php$" ||
req.url ~ "^/admin$" ||
req.url ~ "^/admin/.*$" ||
req.url ~ "^/user$" ||
req.url ~ "^/user/.*$" ||
req.url ~ "^/flag/.*$" ||
req.url ~ "^.*/ajax/.*$" ||
req.url ~ "^.*/ahah/.*$") {
return (pass);
}
## BACKUP AND MIGRATE MODULE ##
# Backup and Migrate is a very popular Drupal module that needs to be excluded
# It won't work with Varnish
if (req.url ~ "^/admin/content/backup_migrate/export") {
return (pipe);
}
## COOKIES ##
# Remove cookies for stylesheets, scripts, and images used throughout the site.
# Removing cookies will allow Varnish to cache those files.
if (req.url ~ "(?i)\.(css|js|jpg|jpeg|gif|png|ico)(\?.*)?$") {
unset req.http.Cookie;
}
# Remove all cookies that are not necessary for Drupal to work properly.
# Since it would be cumbersome to REMOVE certain cookies, we specify
# which ones are of interest to us, and remove all others. In this particular
# case we leave SESS, SSESS and NO_CACHE cookies used by Drupal's administrative
# interface. Cookies in cookie header are delimited with ";", so when there are
# many cookies, the header looks like "Cookie1=value1; Cookie2=value2; Cookie3..."
# and so on. That allows us to work with ";" to split cookies into individual
# ones.
#
# The method for filtering unnecessary cookies has been adopted from:
# https://fourkitchens.atlassian.net/wiki/display/TECH/Configure+Varnish+3+for+Drupal+7
if (req.http.Cookie) {
# 1. We add ; to the beginning of cookie header
set req.http.Cookie = ";" + req.http.Cookie;
# 2. We remove spaces following each occurence of ";". After this operation
# all cookies are delimited with no spaces.
set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";");
# 3. We replace ";" INTO "; " (adding the space we have previously removed) in cookies
# named SESS..., SSESS... and NO_CACHE. After this operation those cookies will be
# easy to differentiate from the others, because those will be the only one with space
# after ";"
set req.http.Cookie = regsuball(req.http.Cookie, ";(SESS[a-z0-9]+|SSESS[a-z0-9]+|NO_CACHE)=", "; \1=");
# 4. We remove all cookies with no space after ";", so basically we remove all cookies other
# than those above.
set req.http.Cookie = regsuball(req.http.Cookie, ";[^ ][^;]*", "");
# 5. We strip leading and trailing whitespace and semicolons.
set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", "");
# If there are no cookies after our striping procedure, we remove the header altogether,
# thus allowing Varnish to cache this page
if (req.http.Cookie == "") {
unset req.http.Cookie;
}
# if any of our cookies of interest are still there, we disable caching and pass the request
# straight to Apache and Drupal
else {
return (pass);
}
}
}
. . .La méthode suivante est le. Cette méthode est responsable du traitement de la réponse d’Apache et de Drupal avant de la mettre en cache ou de la supprimer du cache. Nous pouvons changer ce que Drupal envoie pour s’intégrer à notre stratégie de mise en cache.
La méthode par défaut ressemble à ceci:
. . .
sub vcl_backend_response {
# Happens after we have read the response headers from the backend.
#
# Here you clean the response headers, removing silly Set-Cookie headers
# and other mistakes your backend does.
}
. . .Remplaçons-le par ce tout nouveau bloc tel quel. Les commentaires sont inclus:
. . .
sub vcl_backend_response {
# Remove cookies for stylesheets, scripts and images used throughout the site.
# Removing cookies will allow Varnish to cache those files. It is uncommon for
# static files to contain cookies, but it is possible for files generated
# dynamically by Drupal. Those cookies are unnecessary, but could prevent files
# from being cached.
if (bereq.url ~ "(?i)\.(css|js|jpg|jpeg|gif|png|ico)(\?.*)?$") {
unset beresp.http.set-cookie;
}
}
. . .Le code supprime les cookies pour les fichiers statiques en utilisant la même méthode de sélection des fichiers qu’avant, afin que les cookies soient supprimés pour les mêmes fichiers dans et.
Sauvegardons le fichier de configuration avec * CTRL + x *, puis * y * suivi de * Entrée *. Changer d’autres méthodes est inutile.
Étape 5 - Redémarrage du vernis
Redémarrez * Varnish * pour que les modifications prennent effet:
sudo service varnish restartLe serveur Varnish doit redémarrer sans erreur.
Vous devriez maintenant pouvoir revoir votre site Web Drupal dans votre navigateur.
Cependant, il reste encore une étape à franchir avant que notre site Drupal ne soit correctement mis en cache. Nous devons activer la mise en cache dans Drupal lui-même.
Étape 6 - Activer le cache dans Drupal
Par défaut, Drupal a ses mécanismes de cache désactivés. Cela entraîne l’envoi d’en-têtes à Varnish, ce qui oblige les pages à ne pas être mises en cache. Ainsi, un cache Drupal désactivé empêchera automatiquement Varnish de nous aider à accélérer le site.
Pour activer la mise en cache Drupal, connectez-vous à votre site Drupal en tant qu’administrateur.
Choisissez le menu * Configuration *, puis * Performance *.
image: https: //assets.digitalocean.com/articles/drupal_varnish/1.png [Menu de configuration Drupal]
Dans la section * Performances *, recherchez et vérifiez les paramètres * Pages du cache pour les utilisateurs anonymes * et * Blocs de cache *.
Définissez la * Durée de vie minimale du cache * et * L’expiration des pages en cache * sur une valeur raisonnable, telle que * 30 minutes *. Cette valeur procure un gain de performances considérable et garantit que le cache n’est pas périmé trop longtemps. Le meilleur paramètre pour la durée de vie du cache dépend du site individuel et de sa fréquence de mise à jour. Après avoir modifié les valeurs, cliquez sur * Save configuration *.
image: https: //assets.digitalocean.com/articles/drupal_varnish/2.png [Paramètres du cache]
Ceci termine la configuration nécessaire pour que Varnish cache notre site Drupal.
Étape 7 - Vérification de la configuration du vernis
Pour vous assurer que Varnish cache le site, nous pouvons utiliser l’outil simple appelé Is Varnish Working?. Entrez l’adresse de votre site Web dans le formulaire. Vous devriez voir une réponse semblable à celle ci-dessous:
image: https: //assets.digitalocean.com/articles/drupal_varnish/3.png [Vernis de travail]
Vous voudrez peut-être vérifier deux fois si vous recevez le "type de" message la première fois.
Lectures complémentaires
Les sujets abordés dans cet article ne sont que la pointe de l’iceberg. * Varnish * est un logiciel très puissant qui peut vous aider avec bien plus que la simple mise en cache. La documentation officielle Varnish est une vaste ressource sur les possibilités de Varnish et la syntaxe VCL. Pour tirer le meilleur parti de Varnish et de Drupal, il est également préférable de connaître les possibilités propres à Drupal en termes d’amélioration des performances. La Drupal Performance Documentation officielle est un bon point de départ.
Varnish est un outil qui peut grandement améliorer les performances de votre site. Mais ce n’est finalement pas une solution magique à tous les goulots d’étranglement des performances. Vous obtiendrez de meilleurs résultats en réalisant une planification minutieuse à toutes les étapes. Cela dit, même la configuration la plus simple * Varnish * peut rendre votre site Web très rapide en quelques minutes.