Mise en cache hautes performances avec NGINX et NGINX Plus

Cet article est adapté d'un webinaire d'Owen Garrett, présenté par Andrew Alexeev.

Table des matières

Introduction

Mise en cache de contenu et NGINX

Contrôle de la mise en cache

Questions et réponses

0:00 Présentation

André Alexeïev : Bienvenue à notre dernier webinaire ; je m'appelle Andrew. NGINX a été écrit par Igor Sysoev avec l'idée d'aider les sites Web du monde entier à fonctionner plus rapidement, à être plus réactifs et à être facilement évolutifs. Aujourd'hui, NGINX équipe plus de 30 % des principaux sites et plus de 20 % de tous les sites Web sur Internet. [ Rédacteur en chef – Ces statistiques s'appliquaient lorsque le webinaire a été diffusé en mai 2014 ; voir les valeurs actuelles ici . ] J'espère que vous trouverez le contenu de ce webinaire utile et applicable à votre environnement NGINX existant ou prévu.

Permettez-moi maintenant de vous présenter Owen Garrett. Owen est responsable du développement de produits chez NGINX. Aujourd'hui, Owen va vous expliquer comment appliquer de puissants mécanismes de mise en cache dans NGINX pour libérer votre application du fardeau de la génération répétée de contenu.

1:22 À propos de ce webinaire

Owen Garrett : Merci, Andrew, et mes amis, merci beaucoup de nous avoir rejoints pendant les 45 ou 50 prochaines minutes. Je vais vous expliquer comment fonctionne NGINX en matière de mise en cache de contenu , nous examinerons certaines des façons dont vous pouvez améliorer les performances, nous examinerons en profondeur le fonctionnement réel de la mise en cache de contenu afin que vous soyez équipé pour déboguer et diagnostiquer ce qui se passe dans NGINX, et je terminerai avec quelques conseils et astuces intelligents pour vous donner un contrôle très précis sur ce que NGINX fait avec le contenu qui peut être mis en cache.

Tous visent les mêmes raisons fondamentales, comme l’a décrit Andrew, pour soulager vos serveurs en amont de la charge de générer du contenu répétitif afin qu’ils soient libérés pour exécuter les applications dont votre entreprise a réellement besoin. Augmentez au-delà de ces serveurs, en offrant à vos utilisateurs finaux un meilleur niveau de service et en augmentant la fiabilité de votre service en tant que trou face aux gros pics de trafic provenant d'Internet et, potentiellement, aux pannes des serveurs en amont.

2:17 Principes de base de la mise en cache de contenu

Avant d’aborder la configuration d’implémentation de NGINX, j’aimerais simplement passer rapidement en revue le fonctionnement de la mise en cache de contenu afin que nous partions tous de la même page, de la même base d’informations de base.

2:35 Principes de base

Le principe de base de la mise en cache de contenu est de décharger le travail répétitif des serveurs en amont. Lorsque le premier utilisateur demande un élément de contenu sur le site Web (illustré par l'icône bleue et les lignes bleues), sa requête HTTP est transmise à NGINX, puis de là au serveur en amont en gris sur le côté droit.

La réponse est transmise à l’utilisateur distant, mais si elle peut être mise en cache (et nous verrons ce que cela signifie sous peu), alors NGINX stocke une copie de cette réponse. Lorsqu'un autre utilisateur, le type orange, arrive et demande le même contenu, NGINX peut le servir directement à partir de son cache local plutôt que de falsifier la demande à partir du serveur en amont.

Ce principe de base de stockage de contenu pouvant être mis en cache et immuable est utilisé par votre navigateur Web, par un CDN, les sites auxquels vous accédez, les CDN d'exploitation et par NGINX sur d'autres appareils. Il fonctionne comme un cache proxy inverse , généralement déployé dans le centre de données ou sur le cloud à côté des serveurs d'origine qui hébergent votre contenu Web et vos applications Web.

3:59 Mécanique de la mise en cache HTTP

Le serveur d'origine déclare la capacité de mise en cache du contenu à l'aide d'un ou plusieurs en-têtes de réponse HTTP bien compris et bien connus. Bien entendu, les serveurs de mise en cache peuvent choisir d’ignorer, de remplacer ou de modifier ce comportement. Mais pour comprendre la mise en cache du contenu configuré, vous devez vraiment commencer par bien comprendre la manière dont un serveur d’origine indiquera que le contenu peut être mis en cache, qu’il est immuable et que la copie [mise en cache] a une certaine durée de vie.

La mise en cache de contenu a commencé avec un simple en-tête de réponse HTTP appelé Expires . Le serveur d'origine présenterait du contenu et déclarerait que ce contenu serait valide jusqu'à la date indiquée dans l'en-tête Expires . Cette méthode a été rapidement dépassée par une méthode plus efficace et plus flexible : l’en-tête Cache-Control .

Expires est quelque peu difficile à utiliser ; il est inefficace. Les dates doivent être correctement formatées et analysées tandis que Cache-Control est beaucoup plus rationalisé et aligné sur les besoins et la vitesse des caches de contenu. Cache-Control déclare le contenu comme public ou privé et, dans le cas où il est public, déclare un âge maximal , c'est-à-dire le nombre de secondes pendant lesquelles il peut être mis en cache avant que l'objet de mise en cache ne doive demander à nouveau ce contenu.

Le troisième en-tête qui contrôle directement la mise en cache est X-Accel-Expires . Cet en-tête est spécial pour NGINX ; seul NGINX le comprend et il est utilisé si vous souhaitez remplacer le comportement des en-têtes ci-dessus et indiquer directement à NGINX combien de temps précisément un élément de contenu doit être mis en cache.

Il existe des situations dans lesquelles vous pouvez souhaiter que le navigateur Web mette en cache le contenu pendant une longue période, mais vous acceptez que le cache proxy (NGINX placé devant le serveur d'origine) le mette en cache pendant une période plus courte afin que les modifications soient reflétées plus rapidement et transmises aux nouveaux clients, tandis que les anciens clients ne continuent pas à demander le contenu lorsqu'ils n'en ont pas besoin.

Cependant, cette méthode peut également être implémentée à l’aide des deux derniers en-têtes. Un serveur d'origine peut déclarer quand un élément de contenu a été modifié pour la dernière fois et il peut déclarer un élément appelé ETag (balise d'entité) - une chaîne opaque, souvent une valeur de hachage, qui identifie ce contenu.

Les clients peuvent ensuite effectuer des requêtes à l’aide de GET conditionnels. Ils peuvent inclure un en-tête If-Modified-Since ou If-None-Match dans leur demande. Ce faisant, le client déclare qu'il dispose d'une version en cache du contenu qui a été modifié pour la dernière fois à une date particulière ou qui possède un ETag particulier. Si la version la plus récente détenue par le serveur correspond à la version du client, le serveur répond simplement par un 304Non modifié . Il s’agit d’une réponse rapide qui permet d’économiser la bande passante du réseau et permet au client de vérifier à son guise si la copie en cache du contenu est toujours valide.

Ces cinq en-têtes définissent du point de vue d'un serveur d'origine comment le contenu peut être mis en cache : sa validité, sa fraîcheur et, en termes d' ETag , les détails du contenu lui-même.

7:46 Que met en cache NGINX ?

Les caches proxy tels que NGINX sont relativement libres d'interpréter dans quelle mesure ils se conformeront strictement à ces en-têtes. Il est clair qu’ils ne devraient pas mettre en cache quelque chose qui n’est pas cachable, mais bien sûr, ils n’ont aucune obligation de mettre en cache quelque chose si le serveur d’origine dit que c’est cachable.

Le comportement de base de NGINX consiste à mettre en cache toutes les requêtes GET et HEAD indiquées par le serveur d'origine comme pouvant être mises en cache, à condition qu'il n'y ait pas d'en-têtes Set-Cookie dans la réponse. C'est parce que les en-têtes Set-Cookie incluent généralement des données uniques spécifiques à chaque demande et, par défaut, il ne serait pas approprié de mettre en cache cette valeur.

NGINX met en cache chaque ressource à l’aide d’une clé particulière : une clé de cache. Toutes les requêtes qui génèrent la même clé de cache seront satisfaites avec la même ressource. Par défaut, le cache est mappé sur l'URL brute ou, dans la configuration, sur la chaîne illustrée sur cette diapositive [ $scheme$proxy_host$uri$is_args$args ]. Au moment où NGINX met en cache le contenu, [la durée de validité] est définie (par ordre de préférence) par l'en-tête X-Accel-Expires s'il est présent ou par l'en-tête Cache-Control ou l'en-tête Expires hérité.

Vous pouvez régler NGINX pour masquer certains de ces en-têtes ou pour fournir un temps de cache fixe à la place, complètement indépendamment de ce que dit le serveur d'origine. Pour référence, la RFC 2616 définit le comportement souhaité d'un cache proxy par rapport à HTTP.

Cela vous donne donc un bref aperçu de l'universalité de la mise en cache et du comportement par défaut de base de NGINX dans la mise en cache du contenu qui est généralement sûr à mettre en cache, afin d'accélérer votre site Web et de soulager vos serveurs d'origine.

9:55 NGINX en opération

Voyons maintenant un peu comment NGINX fonctionne. Il est vraiment très simple de configurer NGINX pour activer la mise en cache de contenu.

10:06 Configuration NGINX

Il s'agit de quelques lignes dans votre fichier de configuration NGINX : une pour créer un cache sur le disque avec un certain ensemble de paramètres déclarant la manière dont les fichiers sont disposés, le délai d'expiration [pour les objets dans ce cache] et la taille de ce cache. Ensuite, la deuxième directive, la directive proxy_cache , est associée à un proxy NGINX et lui indique que le contenu (résultats, réponses) doit être mis en cache dans un cache nommé.

Donc ici, j'ai créé un cache appelé un ; il fait 10 Mo de taille en mémoire pour les métadonnées mais est illimité en taille sur le disque pour le contenu mis en cache. Le contenu est mis en cache puis récupéré s'il est inactif depuis 60 minutes. Ce cache appelé un est utilisé par notre serveur par défaut. Ces deux [directives], proxy_cache_path et proxy_cache , sont suffisantes pour permettre une mise en cache fiable et cohérente pour un serveur proxy dans NGINX.

11:14 Processus de mise en cache

Le processus que NGINX subit lorsqu'il reçoit une demande et interroge un cache est défini comme suit. Nous commençons par lire une requête (case en haut à gauche de cette diapositive), en assemblant la clé de cache à l’URI brut et aux autres paramètres que nous allons utiliser pour identifier la ressource correspondant à cette requête. Nous vérifions ensuite le cache sur le disque en accédant aux métadonnées en mémoire pour voir si nous avons une copie valide et récente de la réponse à cette demande.

Si nous le faisons, cela compte comme un coup sûr. NGINX peut alors répondre directement depuis le cache. Il répond à partir du cache en diffusant le contenu du disque exactement comme NGINX diffuse le contenu statique. Vous obtenez ainsi le niveau de performance, de fiabilité et d’évolutivité pour lequel NGINX a été conçu. Avec du contenu statique, vous obtenez exactement le même degré [de performance] lorsque vous diffusez du contenu à partir du cache de contenu de NGINX.

D'un autre côté, lorsque nous vérifions le cache, nous pouvons avoir un échec de cache. Cela signifie que nous n’avons pas le contenu dans le cache, ou que le contenu du cache est obsolète et doit être actualisé. Dans le cas le plus simple, cela signifie que nous demanderions ce contenu au serveur d’origine, recevrions la réponse et vérifierions s’il peut être mis en cache.

Si c’est le cas, nous le diffusons sur le disque comme le fait NGINX pour toute réponse volumineuse traitée en mode proxy. Ensuite, une fois que la réponse est diffusée sur le disque, nous la copions dans le cache et répondons directement à partir du cache. L’un des défis de cette approche est que si NGINX reçoit plusieurs demandes pour le même contenu en même temps et qu’elles aboutissent toutes à un échec.

NGINX transmet normalement toutes ces requêtes au serveur d’origine, le surchargeant potentiellement, en particulier pour les requêtes qui prennent beaucoup de temps à générer des réponses. C'est pour cette raison que vous pouvez utiliser un verrou de cache. La directive proxy_cache_lock garantit que si un élément de contenu est actualisé, une seule requête à la fois est envoyée au serveur en amont.

Ainsi, dans le scénario que j'ai décrit, la première requête irait au serveur en amont, mais les requêtes restantes pour le même contenu seront retenues jusqu'à ce que la réponse ait été servie et insérée dans le cache (auquel cas toutes les requêtes peuvent être satisfaites), ou qu'un délai d'attente soit atteint [défini par la directive proxy_cache_lock_timeout ] - NGINX a attendu suffisamment longtemps pour que le contenu revienne du serveur et à ce stade, les requêtes que vous avez publiées sont transmises au serveur d'origine.

Ainsi, le proxy_cache_lock et le timeout vous offrent un contrôle puissant pour garantir que lorsque vous avez un site occupé avec de nombreuses demandes pour le même contenu, si ce contenu expire dans le cache, vous ne surchargez pas soudainement le serveur d'origine avec plusieurs demandes.

Il y a un autre élément du processus de mise en cache dans NGINX qui ne s'intègre pas parfaitement dans cet organigramme, car il couvre presque toutes les étapes du graphique. C'est la capacité configurée avec la directive proxy_cache_use_stale . À tout moment, si l'une de ces étapes échoue pour une raison quelconque, par exemple lorsque nous mettons à jour le contenu et que nous atteignons un délai d'attente ou que nous obtenons une mauvaise réponse du serveur en amont ou un autre type d'erreur, nous avons la possibilité de répondre directement depuis le cache même si le contenu mis en cache est obsolète.

Il s’agit d’un outil vraiment puissant au cas où vos serveurs en amont seraient surchargés de trafic ou tomberaient en panne en raison d’une maintenance ou d’une erreur catastrophique. Il garantit que NGINX peut continuer à diffuser votre contenu en utilisant le contenu obsolète du cache plutôt que de renvoyer un message d'erreur au client.

15:32 La mise en cache ne concerne pas uniquement HTTP

La mise en cache dans NGINX ne concerne pas uniquement HTTP. NGINX est bien plus qu’un simple proxy HTTP qui transmet les requêtes aux serveurs Web en amont. En général, ces serveurs Web en amont sont là pour s'interfacer avec des API comme FastCGI ou SCGI. NGINX peut le faire directement à la manière d'un proxy, très similaire au proxy HTTP.

NGINX peut utiliser ses techniques de mise en cache pour les proxys HTTP , pour les proxys FastCGI , pour les proxys uWSGI et pour les proxys SCGI . Tous fonctionnent de la même manière que le proxy HTTP, avec des caches stockés sur le disque et des réponses directes, évitant ainsi le besoin de recourir à un proxy vers ces services en amont.

NGINX peut également s'interfacer avec un serveur memcached ; il s'agit d'une approche de mise en cache légèrement différente. Dans ce cas, NGINX ne stocke pas directement le contenu, il utilise memcached comme proxy et s’appuie sur un agent externe pour remplir memcached avec le contenu nécessaire. Cela peut être un autre outil utile, et il existe de nombreuses façons de remplir memcached à partir d'un site externe si nécessaire. Vous pouvez donc considérer cela comme un moyen de créer un cache pour NGINX si cela correspond à vos besoins professionnels.

17:10 Comment comprendre ce qui se passe

La mise en cache peut potentiellement être très complexe si vous disposez d'une grande infrastructure avec plusieurs niveaux, certains effectuant la mise en cache, d'autres non, certains générant du contenu, d'autres non ; il peut alors être assez difficile de commencer à suivre ce qui se passe – d'où vient le contenu – et de diagnostiquer et de déboguer les problèmes que vous rencontrez. Chez NGINX, nous vous facilitons la tâche autant que possible.

17:38 Instrumentation du cache

Avec une instrumentation sophistiquée, vous avez la possibilité de contrôler l’instrumentation de manière dynamique pour suivre la provenance du contenu, où il est stocké dans le cache et quel est son statut dans le cache.

La première étape est la variable $upstream_cache_status , qui est calculée pour chaque requête à laquelle NGINX a répondu, qu'elle provienne du cache ou non. Et vous ajoutez continuellement la valeur de cette variable à votre réponse en utilisant la directive add_header . Traditionnellement, nous mettons cette valeur dans un en-tête X-Cache-Status dans la réponse. Il peut prendre l'une des sept valeurs différentes, déclarant comment ce contenu a été diffusé. Qu'il ait contourné le cache, qu'il provienne d'une revalidation, qu'il s'agisse d'un succès.

C’est la première étape pour essayer de comprendre d’où viennent vos réponses. Proviennent-ils du cache NGINX local ou d’un serveur en amont ? Et vous pouvez inspecter cet en-tête de réponse de différentes manières : à partir de la ligne de commande à l’aide d’outils comme curl , ou très souvent dans votre navigateur Web à l’aide de débogueurs interactifs.

Bien sûr, vous ne souhaiterez peut-être pas déclarer cette valeur à tous vos utilisateurs finaux. Vous souhaiterez être sélectif quant au moment où vous insérez cette valeur dans la réponse d’en-tête.

19:08 Instrumentation du cache (suite)

Le langage de configuration de NGINX vous donne la flexibilité d'être sélectif. Cet exemple montre seulement l’une des nombreuses façons dont vous pouvez procéder. Nous prenons l'adresse distante et si elle se trouve être localhost, alors nous mettrons le $upstream_cache_status dans une variable temporaire ( $cache_status ). Enfin, lorsque nous renvoyons une réponse, nous insérons une variable temporaire dans la réponse.

De cette façon, seules les requêtes provenant d'adresses IP sélectives verront la valeur de la variable $upstream_cache_status . Vous pouvez également faire beaucoup d’autres choses ; nous verrons bientôt comment le contenu est stocké sur le disque. Vous pouvez mettre la clé utilisée pour calculer l'emplacement sur le disque dans la réponse. Vous pouvez placer toutes sortes de paramètres dans la réponse pour vous aider à diagnostiquer le cache pendant son exécution.

20:09 État du cache

NGINX Plus , notre version commerciale de NGINX, fournit un certain nombre de fonctionnalités supplémentaires qui aident dans les cas d'utilisation tels que la mise en cache. NGINX Plus est une version commercialement soutenue de NGINX, conçue par notre équipe d'ingénierie à Moscou et soumise à un ensemble complet de tests de régression pour garantir un fonctionnement correct.

NGINX Plus contient également un certain nombre de fonctionnalités destinées aux entreprises qui souhaitent utiliser NGINX comme proxy inverse et équilibreur de charge. Fonctionnalités autour de l'équilibrage de charge, des contrôles de santé et du streaming vidéo avancé. Et dans ce contexte, des fonctionnalités autour d’un statut étendu, de meilleurs diagnostics et une visualisation de ce qui se passe dans NGINX.

[Éditeur – La diapositive ci-dessus et le paragraphe suivant ont été mis à jour pour faire référence à l’ API NGINX Plus , qui remplace et désapprouve le module d’état distinct initialement décrit ici.]

Pour une démonstration, vous pouvez accéder à demo.nginx.com/dashboard.html et vous verrez une page Web qui affiche les données d'état publiées à partir de NGINX Plus à l'aide de l' API NGINX Plus . Et si vous exécutez la commande curl indiquée, vous verrez les données JSON brutes extraites directement du binaire NGINX Plus (ici, elles sont transmises à l'utilitaire jq pour placer chaque élément sur sa propre ligne et indenté hiérarchiquement).

Dans ces données JSON, vous trouverez des données en temps réel sur l’état de chacun des caches de votre déploiement NGINX Plus. Ceci, ainsi que la variable $upstream_cache_status et les autres façons dont vous pouvez instrumenter le cache, vous donnent un très bon aperçu de la manière dont NGINX met en cache le contenu et vous permet d'explorer en profondeur les requêtes individuelles, pour déterminer si cette requête provient du cache ou non et l'état actuel dans le cache.

21:57 Fonctionnement de la mise en cache de contenu dans NGINX

Maintenant que nous avons vu comment nous pouvons examiner la mise en cache des contacts de l’extérieur, examinons-la de l’intérieur. Comment cela fonctionne-t-il dans NGINX ? Comme je l’ai mentionné précédemment, le cache de contenu dans NGINX fonctionne de la même manière que les fichiers sur le disque. Vous obtenez les mêmes performances, la même fiabilité, les mêmes optimisations du système d'exploitation lorsque vous diffusez du contenu à partir de notre cache de contenu que lorsque vous diffusez du contenu statique – les performances qui font la renommée de NGINX.

22:40 Comment ça marche

Le cache de contenu est stocké sur le disque dans un cache persistant. Nous travaillons en collaboration avec le système d'exploitation pour échanger ce cache disque contre de la mémoire, en fournissant des indications au cache de page du système d'exploitation quant au contenu qui doit être stocké en mémoire. Cela signifie que lorsque nous devons diffuser du contenu à partir du cache, nous pouvons le faire extrêmement rapidement.

Les métadonnées autour du cache, les informations sur ce qui s'y trouve et son délai d'expiration, sont stockées séparément dans une section de mémoire partagée sur tous les processus NGINX et sont toujours présentes en mémoire. Ainsi, NGINX peut interroger le cache, rechercher dans le cache, extrêmement rapidement ; il n'a besoin d'accéder au cache de la page que lorsqu'il doit extraire la réponse et la renvoyer à l'utilisateur final.

Nous verrons comment le contenu est stocké dans le cache, nous verrons comment ce cache persistant est chargé dans les processus de travail NGINX vides au démarrage, nous examinerons certaines des opérations de maintenance que NGINX effectue automatiquement sur le cache, et nous terminerons en examinant comment vous pouvez supprimer manuellement le contenu du cache dans des situations particulières.

23:53 Comment le contenu mis en cache est-il stocké ?

Vous vous souvenez que le cache de contenu est déclaré à l'aide d'une directive appelée proxy_cache_path . Cette directive spécifie le nombre de paramètres : où le cache est stocké sur votre système de fichiers, le nom du cache, la taille du cache en mémoire pour les métadonnées et la taille du cache sur le disque. Dans ce cas, il y a un cache de 40 Mo sur le disque.

La clé pour comprendre où le contenu est stocké est de comprendre la clé de cache, l’identifiant unique que NGINX attribue à chaque ressource pouvant être mise en cache. Par défaut, cet identifiant est construit à partir des paramètres de base de la requête : le schéma, l'en-tête de l'hôte , l'URI et tous les arguments de chaîne.

Mais vous pouvez étendre cela si vous le souhaitez en utilisant des éléments tels que des valeurs de cookies ou des en-têtes d'authentification ou même des valeurs que vous avez calculées au moment de l'exécution. Peut-être souhaitez-vous stocker des versions différentes pour les utilisateurs au Royaume-Uni et pour les utilisateurs aux États-Unis. Tout cela est possible en configurant la directive proxy_cache_key .

Lorsque NGINX traite une requête, il calcule le proxy_cache_key et à partir de cette valeur, il calcule ensuite une somme MD5. Vous pouvez reproduire cela vous-même en utilisant l'exemple de ligne de commande que j'ai montré plus bas sur la diapositive. Nous prenons la clé de cache httplocalhost:8002/time.php et la pompons via md5sum . Soyez prudent, lorsque vous faites cela à partir du shell, de ne pas également pomper une nouvelle ligne.

Cela calculera la valeur de hachage MD5 qui correspond à ce contenu pouvant être mis en cache. NGINX utilise cette valeur de hachage pour calculer l'emplacement sur le disque où le contenu doit être stocké. Vous verrez dans proxy_cache_path que nous spécifions un cache à deux niveaux avec un répertoire à un caractère puis à deux caractères. Nous extrayons ces caractères de la fin de la chaîne pour créer un répertoire appelé4 et un sous-répertoire appelé 9b , puis nous déposons le contenu du cache (plus les en-têtes et une petite quantité de métadonnées) dans un fichier sur le disque.

Vous pouvez tester la mise en cache du contenu. Vous pouvez imprimer la clé de cache comme l'un des en-têtes de réponse, vous pouvez la pomper via md5sum pour calculer la correspondance de hachage de cette valeur. Vous pouvez ensuite inspecter la valeur sur le disque pour voir qu'elle est vraiment là et les en-têtes mis en cache par NGINX, pour comprendre comment tout cela s'articule.

26:36 Chargement du cache à partir du disque

Maintenant que le contenu est stocké sur le disque et est persistant, lorsque NGINX démarre, il doit charger ce contenu en mémoire – ou plutôt, il doit parcourir ce cache disque, extraire les métadonnées, puis charger les métadonnées en mémoire dans le segment de mémoire partagée utilisé par chacun des processus de travail. Cela se fait à l’aide d’un processus appelé chargeur de cache .

Un chargeur de cache démarre au démarrage et s'exécute une fois, chargeant les métadonnées sur le disque par petits morceaux : 100 fichiers à la fois, mis en sandbox à 200 ms, puis en faisant une pause de 50 ms entre les deux, puis en répétant jusqu'à ce qu'ils aient parcouru l'intégralité du cache et rempli le segment de mémoire partagée.

Le chargeur de cache se ferme alors et n’a pas besoin de s’exécuter à nouveau, sauf si NGINX est redémarré ou reconfiguré et que le segment de mémoire partagée doit être réinitialisé. Vous pouvez régler le fonctionnement du chargeur de cache, ce qui peut être approprié si vous avez des disques très rapides et une charge légère. Vous pouvez le faire fonctionner plus rapidement ou peut-être souhaiterez-vous le ralentir un peu si vous stockez un cache avec un grand nombre de fichiers et des disques lents et que vous ne voulez pas que le chargeur de cache utilise des quantités excessives de CPU au démarrage de NGINX.

28:07 Gestion du cache du disque

Une fois que le cache est en mémoire et que les fichiers sont stockés sur le disque, il existe un risque que les fichiers mis en cache qui ne sont jamais consultés restent indéfiniment. NGINX les stockera la première fois qu'il les verra, mais s'il n'y a plus de demandes pour un fichier, alors [le fichier] restera simplement sur le disque jusqu'à ce que quelque chose arrive et le nettoie.

Il s'agit du gestionnaire de cache ; il s'exécute périodiquement, purgeant les fichiers du disque qui n'ont pas été consultés pendant une certaine période de temps, et il supprime les fichiers si le cache est trop gros et a dépassé sa taille déclarée. Il les supprime de la manière la moins récemment utilisée. Vous pouvez configurer cette opération à l'aide de paramètres de la directive proxy_cache_path , tout comme vous configurez le chargeur de cache :

• Le temps d'inactivité par défaut est de 10 minutes.
• Le paramètre max-size n'a pas de limite par défaut. Si vous imposez une limite de taille maximale au cache, il peut parfois dépasser cette limite, mais lorsque le gestionnaire de cache s'exécute, il élague les fichiers les moins récemment utilisés pour les ramener en dessous de cette limite.

29:22 Purge du contenu du disque

Il peut arriver que vous souhaitiez purger le contenu du disque. Vous souhaitez rechercher un fichier et le supprimer ; c'est relativement facile à faire si vous connaissez les techniques dont nous avons parlé plus tôt (exécuter la clé de cache via md5sum ) ou simplement exécuter un grep récursif sur le système de fichiers pour essayer d'identifier le ou les fichiers que vous devez supprimer.

Alternativement, si vous utilisez NGINX Plus, vous pouvez utiliser la fonction de purge du cache intégrée à ce produit. La capacité de purge du cache vous permet de récupérer un paramètre particulier de la demande ; en général, nous utilisons une méthode appelée PURGE pour identifier qu'il s'agit d'une demande de purge du cache.

La purge est gérée par un gestionnaire NGINX Plus spécial qui inspecte l'URI et supprime tous les fichiers correspondant à cet URI du cache. L'URI peut être suffixé par un astérisque afin qu'il devienne une racine. Dans ce cas, nous allons utiliser la capacité de purge pour supprimer chaque fichier servi à partir du port hôte localhost 8001, mais bien sûr, vous pouvez également mettre des sous-répertoires.

Quelle que soit la méthode que vous utilisez, vous pouvez à tout moment supprimer en toute sécurité des fichiers du cache sur le disque ou même rm -rf l'intégralité du répertoire de cache. NGINX ne manquera pas une étape ; il continuera à vérifier la présence de fichiers sur le disque. S'ils manquent, cela crée un manque de cache. NGINX récupérera ensuite le cache du serveur d'origine et le stockera dans le cache sur le disque. C'est donc toujours sûr, fiable et stable si vous devez effacer des fichiers individuels du cache.

31:27 Contrôle de la mise en cache

Nous avons donc examiné le fonctionnement de la mise en cache, nous avons examiné l’implémentation dans NGINX et avons étudié en profondeur la manière dont il stocke les fichiers sur le disque pour obtenir le même type de performances qu’avec le contenu statique. Voyons maintenant un peu plus intelligemment la mise en cache.

Pour les sites simples, vous pouvez activer la mise en cache et, en général, elle fera exactement ce qu'elle doit faire pour continuer à vous offrir le niveau de performance et le comportement de cache souhaité. Mais il y a toujours des optimisations à faire et il y a souvent des situations où le comportement par défaut ne correspond pas au comportement souhaité.

Peut-être que vos serveurs d’origine ne définissent pas les en-têtes de réponse corrects ou peut-être que vous souhaitez remplacer ce qu’ils spécifient dans NGINX lui-même. Il existe une multitude de façons de configurer NGINX pour affiner le fonctionnement de la mise en cache.

32:30 Mise en cache différée

Vous pouvez retarder la mise en cache. Il s’agit d’une situation très courante si vous disposez d’un large corpus de contenu dont une grande partie n’est consultée qu’une ou deux fois par heure ou par jour. Dans ce cas, si vous avez une brochure d'entreprise que très peu de personnes lisent, c'est souvent une perte de temps d'essayer de mettre en cache ce contenu. La mise en cache différée vous permet de mettre en place un filigrane. Il ne stockera une version en cache de ce contenu que s'il a été demandé un certain nombre de fois. Tant que vous n'avez pas atteint le filigrane proxy_cache_min_uses , aucune version ne sera stockée dans le cache.

Cela vous permet d'exercer une plus grande discrimination quant au contenu placé dans votre cache. Le cache lui-même est une ressource limitée, généralement limitée par la quantité de mémoire dont vous disposez sur votre serveur, car vous devez vous assurer que le cache est paginé en mémoire autant que possible. Vous souhaitez donc souvent limiter certains types de contenu et mettre uniquement les requêtes populaires dans votre cache.

La revalidation du cache est une fonctionnalité qui a été récemment ajoutée à NGINX Open Source et NGINX Plus. Il modifie la capacité If-Modified-Since de sorte que lorsque NGINX doit actualiser une valeur qui a été mise en cache, il n'effectue pas un simple GET pour obtenir une nouvelle version de ce contenu ; il effectue un GET conditionnel, en disant : « J'ai une version en cache qui a été modifiée à cette heure et à cette date particulières ».

Le serveur d'origine a la possibilité de répondre avec 304Non modifié , ce qui signifie en fait que la version que vous possédez est toujours la version la plus récente qui existe. Cela permet d'économiser de la bande passante en amont ; le serveur d'origine n'a pas besoin de renvoyer du contenu qui n'a pas changé et cela permet également d'économiser potentiellement des écritures sur le disque. NGINX n'a pas besoin de diffuser ce contact sur le disque, puis de le remplacer en place, en écrasant l'ancienne version.

34:45 Contrôle du temps de mise en cache

Vous disposez d’un contrôle précis sur la durée pendant laquelle le contenu doit être mis en cache. Très souvent, le serveur d’origine fournit du contenu avec des en-têtes de cache adaptés aux navigateurs – une mise en cache à long terme avec une demande relativement fréquente d’actualisation du contenu. Cependant, vous aimeriez peut-être que le proxy NGINX soit placé directement devant votre serveur d'origine pour actualiser les fichiers un peu plus souvent, afin de détecter les modifications plus rapidement.

La charge augmente considérablement si vous réduisez le délai d’expiration du cache pour les navigateurs de 60 à 10 secondes, mais la charge augmente très légèrement si vous augmentez le délai d’expiration du cache dans NGINX de 60 à 10 secondes. Pour chaque requête, cela ajoutera cinq requêtes supplémentaires par minute à vos serveurs d'origine alors qu'avec les clients distants, tout dépend du nombre de clients avec des choses similaires actives sur votre site.

Vous pouvez donc outrepasser la logique et l’intention indiquées par votre serveur d’origine. Vous pouvez masquer ou demander à NGINX d’ignorer certains en-têtes : X-Accel-Expires , Cache-Control ou Expires . Et vous pouvez fournir une durée de cache par défaut en utilisant la directive proxy_cache_valid dans votre configuration NGINX.

36:18 Cache / Ne pas mettre en cache

Il se peut que vous ne mettiez pas en cache le contenu que le serveur d'origine considère comme pouvant être mis en cache, ou que vous souhaitiez vous assurer de contourner la version du contenu stockée dans NGINX. Les directives proxy_cache_bypass et proxy_no_cache vous offrent ce degré de contrôle.

Vous pouvez les utiliser comme raccourci pour dire que si l'un des en-têtes de requête d'un certain ensemble est défini, comme l'autorisation HTTP, ou si un paramètre de requête est présent, vous souhaitez alors contourner le cache – soit pour mettre à jour automatiquement le cache dans NGINX, soit pour simplement l'ignorer complètement et toujours le récupérer à partir du serveur d'origine.

En général, ces opérations sont effectuées pour des décisions de mise en cache assez complexes, où vous prenez des décisions précises sur les valeurs des cookies et des en-têtes d'autorisation pour contrôler ce qui doit être mis en cache, ce qui doit toujours être reçu du serveur d'origine et ce qui ne doit jamais être stocké dans le cache NGINX.

37:25 Caches multiples

Enfin, pour les déploiements à très grande échelle, vous souhaiterez peut-être explorer plusieurs caches au sein d’une instance NGINX individuelle, pour plusieurs raisons. Vous pouvez avoir des politiques de cache différentes pour différents locataires sur votre proxy NGINX, en fonction de la nature de votre site et de l'importance des performances de ce site, voire en fonction du plan particulier auquel chaque locataire est inscrit dans une situation d'hébergement partagé.

Ou vous pouvez avoir plusieurs disques dans l’hôte NGINX et il est plus efficace de déployer un cache individuel sur chaque disque. La règle d'or est de minimiser le nombre de copies d'un disque à un autre et vous pouvez le faire en épinglant un cache sur chaque disque et en épinglant le fichier temporaire de chaque proxy qui utilise ce cache sur le bon disque.

Le fonctionnement standard est le suivant : lorsque NGINX reçoit du contenu d’un proxy en amont, il diffuse ce contenu sur le disque, à moins qu’il ne soit suffisamment petit et qu’il tienne dans la mémoire. Ensuite, une fois que ce contenu est diffusé sur le disque, il est déplacé vers le cache. Cette opération est infiniment plus efficace si l’emplacement sur le cache des fichiers temporaires (le disque sur lequel les fichiers temporaires sont stockés) est le même que le disque sur lequel le cache est stocké.

39:07 Revue rapide – Pourquoi mettre en cache ?

Nous avons donc parlé de la mise en cache, des méthodes utilisées par NGINX, de l'implémentation dans NGINX et des moyens de l'ajuster. Alors que nous approchons de la fin, faisons un rapide retour en arrière pour nous rappeler pourquoi vous souhaitez mettre en cache du contenu en premier lieu. NGINX est déployé sur 114 millions de sites Web dans le monde et bon nombre de ces utilisateurs déploient NGINX en raison de ses capacités d'accélération Web et de mise en cache de contenu. [ Rédacteur en chef – Cette statistique s'appliquait lorsque le webinaire a été diffusé en mai 2014. ]

39:44 Pourquoi la vitesse de la page est-elle importante ?

Ces fonctionnalités améliorent la vitesse d’un site Web – elles offrent aux utilisateurs finaux un meilleur niveau d’expérience – et la vitesse d’une page Web est vraiment, vraiment importante. Depuis des années, les analystes surveillent le comportement des utilisateurs et élaborent ce que l’on appelle familièrement la « règle des N secondes ». C'est le temps qu'un utilisateur moyen est prêt à attendre que la page se charge et s'affiche avant de s'ennuyer, de s'impatienter et de passer à un autre site Web, vers un concurrent.

À mesure que les normes s’améliorent et que les attentes des utilisateurs deviennent de plus en plus élevées, la période pendant laquelle les utilisateurs sont prêts à attendre diminue de plus en plus. On pourrait, grâce à des calculs mathématiques quelque peu douteux, extrapoler et conclure que les utilisateurs auront un niveau de patience négatif d’ici 2016.

40:46 Google a changé les règles

Mais en fait, la technologie nous a dépassé. Google l’a illustré graphiquement il y a quelques années en introduisant Google Instant Search. Désormais, avec Google, lorsque vous saisissez un terme de recherche dans un champ de recherche, avant même d'avoir terminé votre saisie, Google présente les résultats de recherche des candidats. Cela illustre l’énorme changement des attentes vis-à-vis de l’Internet moderne. Comme Google l’a lui-même déclaré, « les utilisateurs s’attendent désormais à ce que les pages Web réagissent de la même manière que lorsqu’on tourne les pages d’un livre » – aussi rapidement, aussi facilement et aussi fluidement.

41:28 Les coûts d'une mauvaise performance

Si vous ne parvenez pas à atteindre ce niveau de performance, cela peut avoir des répercussions importantes sur les indicateurs de performance clés que vous associez à votre site Web ou à votre service Web. Qu'il s'agisse des taux de clics publicitaires : Google lui-même a constaté que son taux de clics publicitaires diminuait de 20 % lorsque ses pages de recherche prenaient une demi-seconde de plus à charger. Qu'il s'agisse de revenus : dans une tentative délibérée d'étudier l'effet des pages Web lentes, Amazon a délibérément augmenté le chargement des pages par multiples de 100 ms et a constaté que les revenus des clients concernés diminuaient généralement de 1 % pour chaque augmentation de 100 ms.

De nombreux autres analystes, sites Web et enquêteurs ont signalé des effets similaires sur les mesures d'un site Web, qu'il s'agisse du temps passé sur la page, du taux de rebond, etc. Plus récemment, Google a commencé à prendre en compte la vitesse des pages lorsqu'il calcule le classement des pages dans les résultats de recherche. Ce qui semble compter, c'est le temps jusqu'au premier octet. Plus le chargement du premier octet d'une page prend du temps, plus votre classement de page est pénalisé. Un site Web peut être confronté au fait qu’il n’est même pas consulté parce qu’il apparaît sur la page trois, quatre ou cinq des résultats de recherche Google.

43:00 La mise en cache NGINX vous permet

Les capacités de mise en cache de NGINX vous permettent d’améliorer l’expérience de l’utilisateur final en réduisant le temps d’accès au premier octet et en rendant le contenu Web plus rapide et plus réactif.

NGINX vous permet de consolider et de simplifier votre infrastructure Web. NGINX n’est pas seulement un cache Web autonome. NGINX inclut un serveur d'origine Web, une passerelle directe vers des API comme FastCGI et, dans NGINX Plus, les capacités permettant de construire un équilibreur de charge et un contrôleur de distribution d'applications sophistiqués et prêts pour l'entreprise. Cela vous permet de consolider plusieurs composants réseau différents de votre infrastructure Web en un seul composant – NGINX ou NGINX Plus – vous offrant ainsi des solutions plus fiables, plus faciles à déboguer et plus rapides.

NGINX vous permet d'augmenter la capacité du serveur en supprimant les tâches répétitives des serveurs en amont. En fait, même pour le contenu qui semble impossible à mettre en cache (la page d’accueil d’un site de blog, par exemple), il est intéressant de le mettre en cache pendant une seconde sur le proxy NGINX.

Lorsqu'une centaine d'utilisateurs demandent le même contenu dans la même seconde, NGINX réduit cela à une seule demande adressée au serveur d'origine et renvoie le contenu à ces utilisateurs à partir de son cache avec la promesse que ce contenu n'est jamais obsolète de plus d'une seconde. C'est souvent plus que suffisant pour un site de blog ou un site Web similaire, mais cela fait une énorme différence en termes de performances, à la fois en termes de charge sur les serveurs en amont et de dépenses liées à la gestion et au déploiement d'une capacité suffisante.

Enfin, n’oubliez pas l’une des utilisations stratégiques de NGINX : vous protéger des pannes des serveurs en amont grâce à la capacité « use stale » du cache proxy. S’ils fonctionnent lentement, s’ils renvoient des erreurs, s’il y a une sorte de défaut, alors NGINX peut revenir à la version locale en cache du contenu et continuer à l’utiliser jusqu’à ce que vos serveurs en amont récupèrent.

45:21 Réflexions finales

38 % des sites Web les plus fréquentés au monde utilisent NGINX principalement pour ses capacités d'accélération Web et de mise en cache de contenu. [ Éditeur – Cette statistique s'appliquait lorsque le webinaire a été diffusé en mai 2014 ; voir la valeur actuelle ici . ] Pour plus de solutions et plus de détails, consultez les blogs et les résumés de fonctionnalités sur nginx.com , qui traitent des capacités de NGINX et NGINX Plus. Et jetez un œil à notre liste de webinaires , pas seulement les futurs webinaires, mais aussi les webinaires qui seront bientôt ajoutés aux événements passés de cette série.

Et si vous souhaitez approfondir ces fonctionnalités, il existe bien sûr la documentation et les solutions que vous pouvez trouver sur nginx.org et nginx.com , mais rien ne vaut le téléchargement et l'essai. Le produit open source est disponible sur nginx.org , ou le produit commercial pris en charge avec des fonctionnalités supplémentaires d'équilibrage de charge, de distribution d'applications, de gestion et de facilité d'utilisation sur nginx.com .

Alors mes amis, merci beaucoup pour votre temps et votre attention. J’espère que cette présentation et ce parcours de la mise en cache de contenu dans NGINX ont été utiles et éclairants pour beaucoup d’entre vous.

Questions et réponses

Commençons par répondre aux questions et voyons comment nous nous en sortons.

47:20 Demandes de plage d'octets

Nous avons une question sur les demandes de plage d’octets. Les requêtes de plage d’octets sont utilisées lorsqu’un client demande un élément de contenu, mais n’a besoin que d’un sous-ensemble de ce contenu. Disons qu’il s’agit d’un fichier vidéo et que le client n’a besoin que d’une partie de la vidéo. Ou, très souvent, il s’agit d’un fichier PDF : l’utilisateur a lu les en-têtes qui contiennent un index dans le fichier PDF, et le client souhaite simplement télécharger un certain ensemble de pages. Comment cela fonctionne-t-il dans le cache de contenu de NGINX ?

Le processus est le suivant. Lorsque NGINX reçoit une demande de plage d’octets pour une ressource et que la ressource entière est déjà dans le cache, NGINX répond à partir du cache avec la plage d’octets demandée par le client. Si cette ressource n’est pas dans le cache, NGINX fera une demande pour la ressource entière au serveur en amont et stockera cette ressource dans le cache. Actuellement, à ce stade, NGINX n’obéira pas à la demande de plage d’octets et renverra l’intégralité de la ressource au client. Dans la plupart des situations, c’est un comportement acceptable.

Par exemple, si un client télécharge un document PDF, sa première demande portera de toute façon sur l’intégralité du document et ce n’est que si ce document est diffusé en continu que le client interrompt la connexion et commence à effectuer des demandes de plage d’octets. Ainsi, pour le contenu mis en cache, NGINX honore les demandes de plage d’octets. Pour le contenu non mis en cache, NGINX récupère l'intégralité du contenu du serveur en amont et renvoie l'intégralité du contenu au client dans cette instance.

49:13 Revalidation du cache proxy

Il s'agit d'une question sur la capacité de revalidation du cache proxy. Il s'agit de la capacité qui permet à NGINX d'effectuer un GET conditionnel sur le serveur en amont pour vérifier si le contenu a changé. La question est :

La revalidation du cache proxy prend-elle en compte les ETag ou simplement la date If-Modified-Since du contenu ?

La réponse est qu'il vérifie simplement la date If-Modified-Since du contenu, et en pratique, c'est généralement une bonne pratique d'inclure toujours If-Modified-Since dans vos réponses et de traiter les ETag comme facultatifs car ils ne sont pas aussi systématiquement ou aussi largement traités que la date de « dernière modification » que vous gérerez dans la réponse.

50:07 Répartition du cache sur des disques égaux

Est-il possible pour NGINX d'équilibrer la charge de sa mise en cache pour un seul site entre quelques disques égaux pour de meilleures performances ?

Oui, c'est vrai, cela demande un peu de travail. Le scénario typique consiste à déployer un ensemble de disques sans RAID, puis à déployer des caches individuels, un épinglé sur chaque disque. Cela nécessite une configuration supplémentaire et un partitionnement du trafic. Si vous avez besoin d'aide pour configurer cela, contactez notre communauté et nous traiterons votre demande spécifique là-bas, ou si vous utilisez NGINX Plus, contactez notre équipe d'assistance et nous serons ravis de vous aider.

50:50 Varier l' en-tête

NGINX prend-il en compte l'en-tête Vary dans les hits et miss du cache ?

Non, NGINX ne gère pas automatiquement les en-têtes Vary . Si cela pose un problème, il est alors simple d’ajouter l’en-tête Vary à la clé de cache proxy afin que la clé unique utilisée pour stocker la réponse inclue la valeur de l’en-tête Vary . Vous pouvez ensuite stocker plusieurs versions différentes.

51:25 Mise en cache des primitives

Toutes les primitives et directives de mise en cache sont-elles respectées ?

En général, oui. Il existe quelques cas limites, tels que les en-têtes Vary , qui ne sont pas respectés. Dans de nombreux cas, il existe une certaine latitude dans la manière dont les différents caches interprètent les exigences de la RFC. Dans la mesure du possible, nous avons opté pour des implémentations fiables, cohérentes et faciles à configurer.

51:52 En-têtes et données en amont

Les en-têtes et les données en amont sont-ils mis en cache ?

Oui, ils le sont. Si vous recevez une réponse du cache, les en-têtes sont mis en cache ainsi que le corps de la réponse.

52:13 *‑Encodage des en-têtes

Les valeurs d'en-tête sont mises en cache ainsi que le corps de la réponse, donc… Je serais assez étonné si NGINX ne fonctionnait pas correctement avec les différentes combinaisons de Transfer-Encoding . Accept-Encoding est souvent implémenté via un en-tête Vary , donc les commentaires précédents sur la nécessité de placer les en-têtes Vary dans votre clé de cache s'appliquent ici (dans le cas des clients qui ne prennent pas cela en charge).

52:56 VITESSE

La mise en cache fonctionne-t-elle pour SPDY ?

Absolument. Vous pouvez le considérer comme un proxy frontal pour NGINX, même si en pratique il est très, très profondément imbriqué dans le noyau NGINX. Oui, SPDY fonctionne pour la mise en cache.

53:15 Tête variable , 2e tour

Voici une autre question sur l'en-tête Vary . Pour confirmer, si vous utilisez des réponses Vary -header et des gzips, jetez un œil à certaines des discussions sur Trac ou sur notre site communautaire pour trouver des solutions à ce problème. L’approche la plus courante consiste à intégrer l’en-tête Vary dans la clé de cache.

53:45 Vitesse de page

Q: PageSpeed utilise-t-il la mise en cache NGINX ou son propre mécanisme de mise en cache ?

C'est une question que vous devrez partager avec les développeurs de PageSpeed .

54:00 Autres caches

Q: Comment les autres caches de contenu se comparent-ils à NGINX ?

Les CDN sont des solutions de mise en cache de contenu très efficaces. Les CDN sont déployés en tant que service ; vous avez un contrôle plus limité sur la manière dont le contenu est mis en cache et sur la manière dont il expire, mais ils constituent un outil très très efficace pour rapprocher le contenu des utilisateurs finaux. NGINX est un outil très efficace pour accélérer l'application Web et très souvent, les deux sont déployés ensemble. Dans le cas des caches autonomes tels que Varnish : encore une fois, ce sont des technologies très performantes qui fonctionnent de manière similaire à NGINX à bien des égards. L’un des avantages de NGINX est qu’il rassemble les passerelles d’application de service d’origine, la mise en cache et l’équilibrage de charge dans une seule solution. Cela vous donne ainsi une infrastructure plus simple, plus consolidée, plus facile à déployer, à gérer, à déboguer et à diagnostiquer en cas de problème.

Pour regarder le webinaire sur lequel cet article est basé, accédez-y ici .

Pour essayer NGINX Plus, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation.