Comment utiliser Varnish et Cloudflare pour une mise en cache maximale –

Cet article fait partie d'une série de sur la construction d'un exemple d'application – un blog de galerie multi-images – pour l'analyse comparative des performances et les optimisations. (Voir le repo ici.)

Comme nous pouvons le voir dans ce rapport la page d'atterrissage de notre site se charge très rapidement et généralement bien, mais elle pourrait utiliser une autre couche de cache

Pour en savoir plus sur GTMetrix et d'autres outils que vous pouvez utiliser pour mesurer et déboguer les performances, voir Amélioration des performances de chargement de pages: Pingdom, YSlow et GTmetrix . Utilisons ce que nous avons appris dans notre précédent Varnish post ainsi que les connaissances acquises dans les messages Intro to CDN et Cloudflare à vraiment régler la livraison de contenu de notre serveur maintenant.

Varnish

Varnish a été créé uniquement dans le but d'être un type de super-cache devant un serveur régulier.

Note: Étant donné que Nginx lui-même est déjà un très bon serveur, les gens optent généralement pour l'un ou l'autre, pas les deux. Il n'y a pas de mal à avoir les deux, mais il faut se méfier des problèmes de cache-cache qui peuvent survenir. Il est important de les configurer correctement pour que le cache de l'un d'entre eux ne reste pas vicié tandis que l'autre est frais. Cela peut conduire à différents contenus affichés à différents visiteurs à des moments différents. La mise en place est un peu en dehors du contexte de ce post, et sera couverte dans un futur guide.

Nous pouvons installer Varnish en exécutant ce qui suit:

 curl -L https://packagecloud.io / varnishcache / vernis5 / gpgkey | sudo apt-key ajouter -
sudo apt-get mise à jour
sudo apt-get installer -y apt-transport-https

La liste actuelle des repos pour Ubuntu ne dispose pas de Varnish 5+, donc des dépôts supplémentaires sont requis. Si le fichier /etc/apt/sources.list.d/varnishcache_varnish5.list n'existe pas, créez-le. Ajoutez-y les éléments suivants:

 deb https://packagecloud.io/varnishcache/varnish5/ubuntu/ xenial main
deb-src https://packagecloud.io/varnishcache/varnish5/ubuntu/ xenial main

Ensuite, lancez:

 sudo apt-get update
sudo apt-get installer vernis
varnishd -V

Le résultat devrait être quelque chose comme:

 $ varnishd -V
varnishd (vernis-5.2.1 révision 67e562482)
Copyright (c) 2006 Verdens Gang AS
Copyright (c) 2006-2015 Varnish Software AS

Nous changeons ensuite le port par défaut du serveur en 8080. Nous le faisons parce que Varnish sera à la place sur le port 80 et redirigera les demandes vers 8080 si nécessaire. Si vous développez localement le Homestead Improved comme indiqué au début de cette série, le fichier que vous devez éditer sera dans /etc/nginx/sites-available/homestead.app Sinon, ce sera probablement dans / etc / nginx / sites-available / default .

 server {
    écoute 8080 default_server;
    écouter [::]: 8080 default_server ipv6only = on;

Ensuite, nous allons configurer Varnish lui-même en éditant / etc / default / vernish et en remplaçant le port par défaut de la première ligne (6081) par 80:

 DAEMON_OPTS = "- a: 80 
   -T localhost: 6082 
   -f /etc/varnish/default.vcl 
   -S / etc / vernis / secret 
   -s malloc, 256m "

La même chose doit être faite dans /lib/systemd/system/varnish.service :

 ExecStart = / usr / sbin / varnishd -j unix, utilisateur = vcache -F -a: 80 -T localhost: 6082 -f /etc/varnish/default.vcl -S / etc / vernis / secret -s malloc, 256m

Enfin, nous pouvons redémarrer Varnish et Nginx pour que les changements prennent effet:

 sudo service nginx restart
sudo /etc/init.d/varnish stop
sudo /etc/init.d/vernish start
démon systemctl-recharger

La dernière commande est là pour que les paramètres du démon varnish.service précédemment édités se rechargent, sinon cela ne prendra en compte que les changements du fichier / etc / default / vernish . La procédure start + stop est nécessaire pour Varnish à cause d'un bogue actuel qui ne libère pas correctement les ports à moins que cela ne soit fait de cette façon.

Comparaison le résultat avec le précédent, nous pouvons voir que la différence est minime du fait que la page de destination est déjà extrêmement optimisée.

Sidenote

Les deux notes basses sont principalement le résultat de nous " GTMetrix se plaignait que des images ne soient pas diffusées depuis une URL « />

Cela se produit parce que nous avons utilisé des images aléatoires pour peupler nos galeries, et le échantillon de l'aléatoire était petit, donc certains d'entre eux sont répétés. C'est très bien et ne sera pas un problème lorsque le site est en production. En fait, c'est l'un des rares cas où un site obtiendra par défaut un meilleur résultat en production qu'en développement.

Cloudflare

Commençons par créer Cloudflare. Tout d'abord, nous enregistrons pour un compte:

Parce que Cloudflare a besoin de certains paramètres DNS appliqués et nécessite donc d'avoir un domaine attaché à une adresse IP (c.-à-d. juste une adresse IP du serveur de destination, comme nous le faisons dans les tests jusqu'à présent), nous devrions enregistrer un domaine de démonstration à cette fin. J'ai un vieux domaine caimeo.com que je peux utiliser pour cela à ce moment, mais d'abord, le domaine doit être connecté à l'adresse IP de la droplet DigitalOcean avec un enregistrement A:

Cloudflare va ensuite scanner et copier ces enregistrements existants, vous permettant également d'ajouter ceux qui manquaient si leur système ne les identifiait pas tous.

A la fin du processus, les serveurs de noms de domaine du bureau d'enregistrement d'origine doivent être mis à jour afin qu'ils pointent vers Cloudflare. À ce stade, Cloudflare contrôle entièrement votre domaine pour vous (bien que la propagation à tous les visiteurs possibles peut prendre jusqu'à 24 heures).

Vous pouvez utiliser le tableau de bord Cloudflare pour voir le niveau du compte et les paramètres appliqués au

Une fois que le service est actif, on peut comparer le nouveau résultat GTMetrix à l'ancien.

Alors que YSlow nous aime maintenant 6% de plus maintenant, il semble que nous puissions faire plus puisque l'intégration de Cloudflare a apparemment ralenti notre site de 23%.

D'abord, essayons d'allumer auto-minification (sous Vitesse dans le Cloudflare Dashboard) et purge complète du cache (sous Caching). Ensuite, nous ferons le test plusieurs fois avant en comparant donc le cache se réchauffe correctement.

C'est mieux! Quelques tests de plus seraient probablement encore plus proches des 1.4s d'origine, mais jetons un coup d'œil à l'outil Rocket Loader de CloudFlare. Il est en version bêta et fonctionne en regroupant tout le JavaScript qu'il peut trouver – même les fichiers externes – et en chargeant de manière asynchrone ces fichiers. Il met ensuite en cache ces ressources localement, dans le navigateur, plutôt que de les récupérer à nouveau à partir d'un serveur distant. Comparaison ici .

Malheureusement, cela laisse à désirer. YSlow nous aime plus car nous minimisons mieux et avons moins de demandes, mais les outils semblent mal configurer certains paramètres qui fonctionnaient beaucoup mieux auparavant. Éteignons-le et purgeons le cache, le réglage précédent était meilleur

Autres réglages possibles

Ne pas oublier le favicon!

Ajouter une favicon est toujours une bonne idée – moins de 404 requêtes et ça va regarde mieux dans le navigateur. En outre, l'écran de cascade nous indique clairement que de ces 1.6s environ 330ms est passé en attendant le favicon!

Boom! Avec notre favicon en place, nous avons rasé encore 300ms.

Nginx tweaks

Vous avez peut-être trouvé ce post après avoir ignoré le Nginx optimisation . Il est recommandé d'appliquer les conseils de celui-ci aussi. Les réglages effectués dans ce post ont été appliqués sur une version live du site, donc sur un serveur différent de celui de ce post. Varnish et Nginx tweaked en tandem ici produisent des résultats encore meilleurs:

 emplacement ~ * . (?: Ico | css | js | gif | jpe? G | png | / raw) $ {
    expire 14d;
}

HTTP / 2

Envisager d'activer HTTP / 2 avec Vernis. Voyez ces lignes de blocage dans le tableau des cascades?

C'est parce qu'ils sont chargés quelques uns à la fois et que les autres attendent que les précédents aient fini de charger. Avec HTTP / 2, ce problème disparaît et tout le site se charge beaucoup plus rapidement en téléchargeant plusieurs fichiers sur la même connexion. Une mise en garde est que le site nécessite un certificat. Avec Let's Encrypt c'est très simple à implémenter ces jours-ci. Une autre mise en garde est que vous avez besoin de reconstruire Nginx avec le module HTTP / 2 inclus, donc un peu de bidouillage sur le serveur est nécessaire. La dernière mise en garde est que HTTP / 2 est toujours en support bêta sur Varnish, et ne devrait probablement pas être trop utilisé .

Pour voir comment configurer Varnish et HTTP / 2, voir Ce tutoriel .

Conclusion

Nous avons implémenté Varnish comme couche de cache supplémentaire, et le plan libre de Cloudflare comme CDN, augmentant ainsi considérablement notre score GTMetrix. Bien que notre processus d'optimisation ait été légèrement exagéré pour une application aussi simple, il est très rassurant de savoir dès le premier jour que notre application est capable de gérer des centaines de milliers d'utilisateurs par seconde sans se briser – et tout cela sur un seul serveur 10 $. 19659005] Si nous avons manqué des étapes et que vous reconnaissez des astuces de performance supplémentaires, faites-le nous savoir!

Bruno est un développeur blockchain et auditeur de code de Croatie avec des Masters en informatique et en anglais. Littérature. Il a été développeur web pendant 10 ans jusqu'à ce que JavaScript le conduise. Il dirige maintenant une entreprise de crypto-monnaie à Bitfalls.com via laquelle il rend la technologie blockchain accessible aux masses, et gère Coinvendor une plateforme d'intégration permettant aux gens d'acheter facilement de la crypto-monnaie. Il est également un développeur évangéliste pour Diffbot.com un grattoir de vision de machine basé sur l'IA basé à San Francisco. En savoir plus sur ses antécédents avec la blockchain ici .