Il y a eu une guerre religieuse en cours depuis un certain temps pour savoir quel est le meilleur cache pour les serveurs Web. Il y a les éternels puristes qui recommandent une cache comme Varnish Cache et les novices qui la recommandent Cache NGINX FastCGI dont nous parlons dans cet article, en tant que méthode plus rapide, plus simple et moins complexe pour fournir la fonctionnalité de mise en cache HTTP (et bien sûr HTTPS).
Il y a ceux comme nous qui soutiennent que Varnish a plus de fonctionnalités et permet, grâce à son langage de configuration Vansh (VLC ed) de générer des configurations et des configurations de mise en cache vraiment complexes et avancées, et il y a ceux qui soutiennent que les mêmes choses peuvent être faites avec quelques lignes de configuration supplémentaires directement dans NGINX, sans ajouter de couches de cache comme Varnish.
Normalement dans ces comparaisons, chacun apporte de l'eau à son moulin, à ce qu'il utilise habituellement, à ce qu'il sait utiliser le plus ou trouve le plus confortable. Par exemple, vous voulez mettre la flexibilité de Varnish Cache et la compatibilité avec WordPress grâce à des plugins standards du marché tels que W3 Total Cache, Proxy Cache Purge, WP Fastest Cache ou le très commercialisé WP Rocket ?
Objectivement, lorsque nous parlons de WordPress et de ses performances, nous sommes les premiers à souligner à quel point il est important pour nous d'avoir une pile basée sur Varnish en tant que cache de page complète. Cependant, a-t-on vraiment raison d'affirmer que le cache NGINX est un "jouet" pour les administrateurs système inexpérimentés ? Et quand certains de nos confrères nous reprochent d'utiliser un cache comme Varnish qui pourrait en fait être sauvegardé grâce au cache NGINX, nous reprochent d'alourdir une pile logicielle qui pourrait être plus allégée, ont-ils vraiment raison ?
Bref, entre Varnish et NGINX quel cache est le meilleur ?
Pour répondre à cette question, il faut nécessairement prendre du recul et s'éloigner de ses convictions, rechercher une approche ouverte vis-à-vis de ce que l'on n'a pas utilisé ou mal utilisé jusqu'à présent et commencer à comprendre les modèles commerciaux de Varnish et NGINX et comment, à partir d'une compréhension de leurs limites respectives, ils peuvent s'inclure et non s'exclure.
Modèles commerciaux de Varnish et NGINX
Varnish et NGINX sont deux serveurs proxy populaires utilisés pour améliorer les performances des applications Web et assurer une meilleure expérience utilisateur. Ce qui rend ces logiciels encore plus intéressants, c'est qu'ils sont tous deux développés selon la philosophie open source, ce qui signifie qu'ils sont librement disponibles pour que quiconque puisse les utiliser et les modifier.
Cependant, il existe également une version commerciale des deux logiciels : NGINX Plus et Varnish Enterprise. Ces versions sont livrées avec des fonctionnalités avancées et des fonctionnalités supplémentaires, qui ne sont pas disponibles dans les versions gratuites. Ces fonctionnalités incluent le support officiel de l'entreprise, les assurances qualité des logiciels et même des outils d'analyse des performances.
Ce qui différencie le plus ces versions commerciales des versions gratuites, c'est leur prix. Les deux versions commerciales ont des coûts de licence de plusieurs dizaines de milliers de dollars par an. Cela signifie que ces licences sont principalement destinées aux entreprises qui ont besoin de fonctionnalités avancées et sont prêtes à payer pour une assistance et des garanties supplémentaires.
Surmontez les limitations respectives en utilisant à la fois NGINX et Varnish
Sachant que NGINX et Varnish ont des limitations dans leurs versions gratuites, nous pouvons toujours les surmonter en utilisant les deux serveurs proxy en combinaison.
Par exemple, NGINX peut être utilisé comme service de microcaching. De cette manière, NGINX est utilisé comme premier niveau de mise en cache, où les données fréquemment demandées par les utilisateurs sont stockées. Lorsqu'une requête arrive sur le serveur, NGINX vérifie son cache pour voir si la réponse s'y trouve déjà. Si c'est le cas, NGINX renvoie immédiatement la réponse au client sans avoir à passer à l'étape suivante du traitement.
En combinaison avec Varnish, NGINX peut être utilisé comme frontal pour le serveur de mise en cache Varnish. Dans ce scénario, les demandes des clients sont initialement traitées par NGINX. Si les données demandées ne se trouvent pas dans le cache de NGINX, la demande est transmise au serveur Varnish, qui dispose d'un cache plus grand et plus robuste. Varnish a la capacité de stocker de grandes quantités de données dans la RAM, ce qui le rend beaucoup plus rapide que les caches classiques comme Memcached et Redis.
Lorsqu'un client demande des informations, NGINX les recherche dans son cache. Si la réponse est là, NGINX l'envoie directement au client. Sinon, la demande est transmise à Varnish, qui à son tour vérifie son cache pour voir si la réponse s'y trouve. Si la réponse est présente dans le cache Varnish, elle est renvoyée au client via NGINX.
Cette combinaison de mise en cache peut améliorer considérablement les performances des applications Web. De plus, il est possible de personnaliser le comportement du cache en utilisant les options de configuration offertes par les deux serveurs proxy et avec quelques précautions pour s'assurer que le serveur web ne renvoie jamais un MISS en réponse, garantissant ainsi d'excellents temps de réponse inférieurs à 30ms.
