Table des matières de l'article :
Nous savons tous que les performances des applications et des sites Web sont essentielles à leur succès. Cependant, le processus d'amélioration des performances des applications ou des sites Web n'est pas toujours clair. La qualité du code et l'infrastructure sont évidemment critiques, mais dans de nombreux cas, vous pouvez apporter des améliorations significatives à l'expérience de l'utilisateur final de votre application en vous concentrant sur certaines techniques de livraison d'application de base. Un tel exemple est la mise en œuvre et l'optimisation de la mise en cache dans la pile d'applications. Cet article de blog couvre les techniques qui peuvent aider les utilisateurs novices et avancés à obtenir de meilleures performances en utilisant les fonctionnalités de mise en cache de contenu incluses dans NGINX et NGINX Plus.
Panoramica
Un cache de contenu se situe entre un client et un "serveur d'origine" et enregistre des copies de tout le contenu qu'il voit. Si un client demande du contenu mis en cache, il renvoie le contenu directement sans contacter le serveur d'origine. Cela améliore les performances car le cache de contenu est plus proche du client et utilise les serveurs d'applications plus efficacement car ils n'ont pas à refaire le travail de génération de page à partir de zéro à chaque fois.
Il existe potentiellement plusieurs caches entre le navigateur Web et le serveur d'applications : le cache du navigateur client, les caches intermédiaires, les réseaux de diffusion de contenu (CDN) et l'équilibreur de charge ou le proxy inverse qui se trouve devant les serveurs d'applications. La mise en cache, même au niveau du proxy inverse/de l'équilibreur de charge, peut considérablement améliorer les performances.
Par exemple, la semaine dernière, j'ai entrepris d'optimiser les performances d'un site Web qui se chargeait lentement. L'une des premières choses que j'ai remarquées, c'est qu'il fallait plus d'une seconde pour générer la page d'accueil principale. Après quelques débogages, j'ai constaté que, comme la page était marquée comme ne pouvant pas être mise en cache, elle était générée dynamiquement en réponse à chaque demande. La page elle-même ne changeait pas très souvent et n'était pas personnalisée, donc ce n'était pas nécessaire. À titre expérimental, j'ai marqué la page d'accueil pour qu'elle soit mise en cache pendant 1 secondes par l'équilibreur de charge et le fait à lui seul a entraîné une amélioration notable. Le temps pour le premier octet est tombé à quelques millisecondes et la page s'est chargée visiblement plus rapidement.
Nous avons beaucoup parlé de NGINX Webserver et comment nous le préférons pour des raisons de performances au plus célèbre Apache.
Cependant, nous avons peu parlé de FastCGI Cache, utilisant Varnish Cache dans l'entreprise pour tous les clients hautes performances.
Cependant, nous assistons à une évolution de nombreux hébergeurs qui proposent FastCGI Cache comme solution Full Page Cache pour le serveur web NGINX.
Nous ne serons pas là pour vous expliquer ce qu'est un FPC (Full Page Cache ndlr), l'ayant déjà fait à plusieurs reprises sur notre blog, mais nous souhaitons entrer dans le vif du sujet en vous parlant de FastCGI Cache qui à première vue peut ressembler à une solution très cache, plus facile que les outils spécifiques à l'entreprise comme Varnish Cache.
Qu'est-ce que le cache Nginx FastCGI ?
Avant de parler de Nginx FastCGI Cache, parlons du fonctionnement de votre site Web.
- Lorsqu'un utilisateur visite votre page WordPress, le navigateur Web envoie une requête HTTP / HTTPS à Nginx.
- Nginx transmet la requête à PHP-FPM et Nginx capture tous les codes PHP lorsqu'il tente de récupérer la page.
- PHP-FPM traite la page et interroge la base de données MariaDB/MySQL pour récupérer la page.
- PHP-FPM envoie la page HTML "statique" générée à Nginx.
- Nginx envoie la page HTML générée au navigateur Web de l'utilisateur.
NGINX inclut un module FastCGI qui contient des directives pour la mise en cache du contenu dynamique servi par le backend PHP. Le paramètre élimine le besoin de solutions de mise en cache de page supplémentaires comme les proxys inverses (pensez à Varnish) ou les plugins spécifiques à l'application. Le contenu peut également être exclu de la mise en cache en fonction de la méthode de requête, de l'URL, des cookies ou de toute autre variable de serveur.
Lors de l'utilisation Nginx FastCGI , ce module Nginx intégré se situera entre Nginx et PHP-FPM et est capable de générer une page HTML en cache à partir de PHP-FPM.
Lorsqu'un autre utilisateur visite la même page WordPress, votre site Web n'effectuera plus les mêmes requêtes PHP et de base de données car la page est déjà mise en cache et servie par FastCGI.
En conséquence, le temps de réponse de votre serveur sera beaucoup plus rapide après le chargement initial.
Votre charge PHP-FPM et MariaDB/MySQL sera réduite.
L'utilisation des ressources CPU de votre serveur sera inférieure.
Et enfin, votre serveur peut gérer plus de trafic avec les mêmes spécifications de serveur lors de l'utilisation de Nginx FastCGI Cache, vous permettant finalement de maintenir un serveur plus abordable sans avoir à évoluer davantage.
Le principal problème de NGINX FastCGI Cache dans la version gratuite.
Il faut dire et rappeler que NGINX a deux modèles de distribution, la version Free que tout le monde connaît et que nous utilisons également et la version Plus appelée NGINX Plus ou NGINX+ qui est la version commerciale payante.
La différence principale et la plus importante entre les deux versions pour ce qui concerne le cache FastCGI est que la fonctionnalité de PURGE ALL dans la version gratuite est manquante par défaut.
En effet, il peut arriver que vous ayez besoin de vider tout le cache dans certaines configurations spécifiques, imaginons un blog qui a les liens des 5 dernières news en pied de page et lors de la rédaction d'une nouvelle news vous devez vider tout le cache de l'ensemble du site.
Alors qu'avec Varnish il suffit d'envoyer un BAN / ou un PURGE ALL pour nettoyer tout le cache du site avec la même rapidité qu'en effectuant une opération de suppression sur le Filesystem (peut-être moins d'une seconde), avec NGINX FastCGI Cache dans le Free version, vous devrez rappeler une par une au niveau applicatif toutes les URL de votre site, en prenant au minimum 1h sur un site de 5000 pages.
Évidemment, pour résoudre ce problème, des modules tiers pour NGINX ont été créés qui vous permettent d'introduire la fonctionnalité de PURGE ALL comme, par exemple, ngx_cache_purge que vous pouvez trouver sur ce lien : https://github.com/torden/ngx_cache_purge
Bref, si vous n'avez pas les épaules larges pour installer un Système de mise en cache d'entreprise tel que Varnish, vous pouvez simplement opter pour la version gratuite en ajoutant ce module.
