Beaucoup a été dit récemment à propos de les mérites des sites statiques . Mais dans de nombreuses situations, une approche dynamique est une nécessité. Qu'il s'agisse d'un système de gestion de contenu, d'un outil de relation client ou d'un magasin en ligne, les utilisateurs finaux peuvent gérer des sites complexes rapidement et de manière cohérente. Et lorsqu'ils sont assemblés correctement, ils peuvent rivaliser avec des sites statiques pour la vitesse.
toute application devant lire et écrire fréquemment des données entraînera un retard notable
Quel que soit le système que vous utilisez, les sites dynamiques comprennent généralement des éléments similaires. Il s’agit d’une forme de serveur Web, d’un backend et d’une application, écrits dans un ou plusieurs langages de programmation. Cette combinaison de composants offre une grande flexibilité, mais chacun apporte sa propre charge et augmente le temps de chargement, ce que tous les sites Web modernes veulent éviter. Cela est particulièrement vrai avec l'accès à la base de données, toute application devant lire et écrire fréquemment des données entraînera un retard notable.
Cela aidera la mise en cache et une stratégie de mise en cache appropriée pour votre cas d'utilisation. L'objectif de base de la mise en cache est d'empêcher les appels inutilement fréquents entre les couches de base de données de l'application et d'utiliser à la place des pages HTML statiques pré-générées, beaucoup plus rapides à rendre dans un navigateur.
Le premier cache qu'un utilisateur Web aurait remarqué est le cache de son navigateur. Combien de fois les développeurs vous ont-ils demandé de procéder à un rafraîchissement forcé pour voir les changements? Les caches de navigateur sont simples mais constituent un bon point de départ pour commencer à expliquer les concepts de mise en cache. Un navigateur stocke des représentations de pages Web visitées sur l'ordinateur d'un utilisateur, en les mettant généralement à jour une fois par session si des modifications sont détectées ou forcées par le site.
Un outil commun employé par les propriétaires de sites et les administrateurs est un «cache de proxy inverse» situé entre les requêtes de page effectuées par un navigateur Web et l'application Web. Il intercepte les requêtes et rend les copies des pages directement à partir du cache, offrant ainsi un gain de vitesse notable.
Plusieurs options principales de cache de proxy sont disponibles pour l'auto-installation ou en tant que "logiciel en tant que service". (Nous ignorons les fournisseurs d'hébergement en nuage qui emballent généralement tout ce dont vous pourriez avoir besoin dans une pile Web autonome.)
Les options de cache proxy les plus courantes sont les suivantes:
Les options SaaS pour la mise en cache se trouvent généralement dans le monde des réseaux de diffusion de contenu (CDN) qui, au lieu de placer un cache entre un utilisateur et une pile Web, servent les ensembles de contenu mis en cache les plus proches. C'est une différence subtile, mais pour les grands sites ayant un public mondial, cela peut faire une différence significative.
Vernis est disponible dans tous les gestionnaires de paquets Linux, comme une image Docker et de nombreuses autres options, lisez la page d'installation du projet pour plus de détails.
Varnish stocke un fichier de configuration par défaut dans /usr/local/etc/varnish/default.vcl ou /etc/varnish/default.vcl , écrit en VCL (Langage de configuration de vernis). Ce fichier de configuration est compilé dans un petit programme via un interpréteur C pour accélérer encore plus la vitesse.
Selon la manière dont vous avez installé Varnish, le fichier de configuration ressemblera à ceci:
backend default {.host = "127.0.0.1";.port = "8000";}Au plus simple, cela définit le backend par défaut utilisé par Varnish, définissant l'hôte et le port qu'il doit écouter et intercepter le contenu.
Une fonctionnalité pratique de Varnish consiste à vérifier à des intervalles prédéfinis si un backend est toujours sain. Il s'appelle 'Backend Polling' et est configuré en ajoutant une section de sonde dans la déclaration backend:
.probe = {.url = '/';.timeout = 34ms;.interval = 1s;.window = 10;.threshold = 8;}Les paramètres ci-dessus sont les paramètres par défaut fournis par Varnish et lui indiquent de visiter un fichier .url particulier à chaque .interval et que, pour au moins le seuil des sondes .window , l'URL réponde en .timeout en millisecondes. Une fois considéré comme "malsain", le contenu est servi depuis le cache pour une période prédéfinie.
Nous couvrirons les modifications spécifiques apportées à la configuration Varnish sous chaque option de plate-forme, pour l'instant, examinons les options générales.
Les ports
Au départ, le port de votre serveur Web devra être modifié par défaut. Par exemple, dans la configuration d'Apache Vhost, remplacez le port par 81 ou 8080.
Démarrez le démon Varnish avec la commande varnish ou en utilisant un wrapper de service. Le démon a des options de drapeau, les plus courantes et les plus utiles étant:
Tout vérifier fonctionne
Exécutez la commande varnishstat ou visitez isvarnishworking.com pour vérifier votre serveur Varnish est prêt et à l'écoute des demandes.
Quoi ne pas mettre en cache
Il y a certaines parties d'un site que nous ne voulons pas mettre en cache, par exemple les pages d'administration. Nous pouvons les exclure en créant un sous-programme vcl_recv dans le fichier default.vcl contenant une instruction if qui définit ce qu'il ne faut pas mettre en cache:
sub vcl_recv {# URI of admin folderif (req.url ~ "^/url/"){return (pass);}return(lookup);}Si vous utilisez Varnish 4, les choses sont légèrement différentes, y compris les valeurs de retour. La fonction vcl_recv renvoie désormais la valeur ahash au lieu d'une recherche.
sub vcl_recv {...return(hash);}C'est également là que nous définissons les sites ou sous-domaines que Varnish doit ignorer en ajoutant un req.http.host ~ 'example.com' à l'instruction if .
Biscuits
Par défaut, Varnish ne met pas en cache le contenu du serveur principal qui définit les cookies. De même, si le client envoie un cookie, il contournera Varnish directement dans le backend.
Les sites sont fréquemment utilisés par les sites pour suivre l'activité de l'utilisateur et stocker des valeurs spécifiques à l'utilisateur. Généralement, ces cookies n'intéressent que le code côté client et ne présentent aucun intérêt pour le backend ou le vernis. Nous pouvons dire à Varnish d'ignorer les cookies, sauf dans certaines zones du site:
if ( !( req.url ~ ^/admin/) ) {unset req.http.Cookie;}Cette instruction if ignore les cookies, sauf si nous sommes dans la zone d'administration du site, où la transmission de cookies peut être plus utile (sauf si vous voulez vraiment frustrer les administrateurs de site).
Autres exceptions
Avec une installation par défaut, Varnish ne cache pas non plus les pages protégées par mot de passe, les requêtes GET et HEAD.
Nous allons maintenant examiner deux cas d'utilisation parfaits pour le vernis: Drupal et Magento. Les deux sont des systèmes très dynamiques qui permettent aux utilisateurs non techniques d'effectuer une grande variété de tâches complexes. Cela peut mener à des chargements de pages trop importants pour les requêtes de la base de données et les sites surchargés deviendront sensiblement plus lents. Les pages typiques construites avec ces systèmes auront un mélange de contenu mis à jour rarement et fréquemment.
Drupal propose des options de mise en cache par défaut qui remplissent des fonctions similaires à Varnish, mais n'offrent pas la flexibilité ou les augmentations de vitesse requises par les sites plus grands ou plus complexes.
En vrai Drupal, il y a un module de gestion de l'intégration des vernis pour sauvegarder une partie de la configuration manuelle décrite ci-dessus.
Installez le module et assurez-vous de suivre les instructions d'installation incluses dans le fichier Lisez-moi du module.
Assurez-vous que le fichier / etc / default / varnish a les options de démon suivantes (et que l'indentation est importante):
DAEMON_OPTS="-a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,128M"Assurez-vous qu'Apache et tous les hôtes virtuels associés écoutent sur le port 8080, et non 80. Redémarrez les deux services après avoir apporté ces modifications.
Vous devrez peut-être définir une clé de contrôle de vernis dans la page de configuration du module. Découvrez ce que cette clé est avec la commande cat / etc / varnish / secret et collez-la dans la page des paramètres. Sélectionnez la version correcte de Varnish, enregistrez les paramètres et vous devriez voir une série de marques vertes au bas de la page.
Le module Varnish interagit avec les paramètres de cache Drupal par défaut. Assurez-vous de l'avoir activé et configuré pour votre cas d'utilisation.
Exécutez varnishstat à partir de la ligne de commande, lancez la navigation sur le site en tant qu'utilisateur anonyme et vous devriez voir les statistiques changer dans la sortie de la commande.
Un des chemins que nous ne voulons pas mettre en cache dans Drupal sont les pages d’administration, nous pouvons le faire avec une sous-routine vcl_recv :
sub vcl_recv {# URI of admin folderif (req.url ~ "^/admin/"){return (pass);}unset req.http.Cookie;return(lookup);}Vous voudrez peut-être envisager de ne pas mettre en cache (connecté) les pages utilisateur, les pages de mise à jour du système et les autres pages générées par des modules hautement dynamiques tels que les indicateurs qui utilisent largement ajax pour fonctionner. Pour ce faire, ajoutez d'autres paramètres req.url à l'instruction if .
Une installation par défaut de Magento est livrée avec un système de mise en cache interne qui stocke les versions statiques des éléments de site dans un dossier spécifié. La page Système -> Gestion du cache fournit une vue d'ensemble de l'état actuel du cache et vous permet d'effacer tout ou partie des caches de composants. Vous pouvez effacer les fichiers CSS et JS agrégés et les fichiers image générés automatiquement à partir de cette page.
La prochaine version de Magento 2 supportera la mise en cache de Varnish par défaut, mais pour le moment nous devons utiliser des plugins tiers, je recommande le Térébenthine . Assurez-vous de lire le fichier readme du projet comme il note quelques étapes de configuration supplémentaires, les ignorer peut casser votre site.
Le module Térébenthine est hautement configurable et apportera les modifications nécessaires aux fichiers vcl et à la configuration de Varnish. Certaines options clés à définir sont les suivantes:
Le module Térébenthine est lié au cache Magento par défaut. Ainsi, effacer les caches de la page du cache Varnish effacera les caches Varnish appropriés.
Outre l'utilisation de Varnish avec l'un des systèmes dynamiques ci-dessus, voici quelques astuces diverses qui aideront à la mise en cache de n'importe quel site.
Si vous diffusez le même contenu dans des contextes différents, il doit utiliser la même URL. Par exemple, ne mélangez pas l'utilisation de article.html , article.htm et article , bien que votre CMS puisse l'autoriser. Cela conduira à trois versions différentes mises en cache du même contenu.
Comme nous l'avons vu ci-dessus, les cookies sont difficiles à mettre en cache et sont rarement aussi nécessaires que nous le pensons. Essayez de limiter leur utilisation et leur nombre aux pages dynamiques.
Le chargement des ressources du site peut être l’une des parties les plus fastidieuses d’un rendu de page et il existe des conseils simples pour réduire ce fardeau:
L'utilisation des images-objets CSS pour l'iconographie au lieu de plusieurs petits fichiers entraîne moins de trafic sur le réseau.
L'hébergement de bibliothèques CSS et JavaScript localement signifie moins de trafic réseau et plus de contrôle sur les stratégies de mise en cache. Cela peut signifier une augmentation des frais de maintenance pour maintenir ces actifs à jour. Stockez ces actifs dans des dossiers nommés de manière cohérente afin que leurs références puissent également être cohérentes.
J'espère que cette introduction à l'accélération de vos sites dynamiques avec la mise en cache était utile. Le gain de performance vaut une période initiale de configuration, d’expérimentation et de réglage. En cette période de temps d’attente et d’impatience, tout gain de vitesse que vous pouvez faire sortir de votre configuration fera la différence pour vos utilisateurs et vos concurrents.
L'image sélectionnée, image de cache réseau via Shutterstock.