Mise en cache haute performance avec NGINX et NGINX Plus

Owen GarrettDirecteur senior de la gestion des produits

Table des matières

Introduction

0:00 Introduction1:22 À propos de ce webinaire2:17 Principes fondamentaux de la mise en cache du contenu2:35 Principes fondamentaux3:59 Fonctionnement de la mise en cache HTTP7:46 Que met NGINX en cache ?

Mise en cache du contenu avec NGINX

9:55 NGINX en fonctionnement10:06 Configuration de NGINX11:14 Processus de mise en cache15:32 La mise en cache ne concerne pas uniquement HTTP17:10 Comment comprendre ce qui se passe17:38 Instrumentation du cache19:08 Instrumentation du cache (suite)20:09 État du cache21:57 Fonctionnement de la mise en cache du contenu dans NGINX22:40 Fonctionnement23:53 Comment le contenu mis en cache est-il stocké ?26:36 Chargement du cache depuis le disque28:07 Gestion du cache sur disque29:22 Purge du contenu du disque

Contrôle de la mise en cache

31:27 Contrôle de la mise en cache32:30 Mise en cache différée34:45 Contrôle de la durée de mise en cache36:18 Mettre en cache / Ne pas mettre en cache37:25 Caches multiples39:07 Récapitulatif rapide – Pourquoi mettre en cache ?39:44 Pourquoi la vitesse de chargement des pages est-elle importante ?40:46 Google a changé les règles41:28 Les coûts liés aux mauvaises performances43:00 La mise en cache NGINX vous permet de45:21 Conclusion

Questions-réponses

47:20 Requêtes par plage d’octets49:13 Revalidation du cache proxy50:07 Répartition du cache sur des disques de même capacité50:50 Vary En-tête51:25 Primitives de mise en cache51:52 En-têtes et données du serveur en amont52:13 *‑Encoding En-têtes52:56 SPDY53:15 Vary En-tête, 2e partie53:45 PageSpeed54:00 Autres caches

0:00 Introduction

Andrew Alexeev : Bienvenue dans notre dernier webinaire ; je m’appelle Andrew. NGINX a été créé par Igor Sysoev dans le but d’aider les sites web du monde entier à être plus rapides, plus réactifs et facilement évolutifs. Aujourd’hui, NGINX équipe plus de 30 % des principaux sites et plus de 20 % de l’ensemble des sites web sur Internet. [Note de la rédaction – Ces statistiques étaient valables lors de la diffusion du webinaire en mai 2014 ; consultez les chiffres actuels ici.] J’espère que le contenu de ce webinaire vous sera utile et pourra s’appliquer à votre environnement NGINX existant ou prévu.

Permettez-moi maintenant de vous présenter Owen Garrett. Owen est responsable du développement des produits chez NGINX. Aujourd’hui, il va vous expliquer comment utiliser les puissants mécanismes de mise en cache de NGINX afin d’éviter à votre application d’avoir à générer sans cesse le même contenu.

1:22 À propos de ce webinaire

Owen Garrett : Merci, Andrew, et merci à toutes et à tous de nous rejoindre pour les 45 à 50 prochaines minutes. Je vais vous expliquer comment NGINX fonctionne en matière de mise en cache du contenu. Nous verrons différentes façons d’améliorer les performances, puis nous examinerons plus en détail le fonctionnement réel de la mise en cache du contenu afin que vous puissiez déboguer et diagnostiquer ce qui se passe dans NGINX. Enfin, je vous donnerai quelques astuces et conseils ingénieux qui vous permettront de contrôler très précisément la manière dont NGINX traite le contenu pouvant être mis en cache.

Tout cela répond aux mêmes objectifs fondamentaux décrits par Andrew : soulager vos serveurs en amont de la production répétitive de contenu afin qu’ils puissent se consacrer aux applications dont votre entreprise a réellement besoin. Cela permet d’aller au-delà des capacités de ces serveurs, d’offrir un meilleur niveau de service à vos utilisateurs finaux et d’accroître la fiabilité globale de votre service face aux fortes hausses de trafic Internet et, éventuellement, aux défaillances des serveurs en amont.

2:17 Principes fondamentaux de la mise en cache du contenu

Avant d’aborder la configuration de la mise en œuvre de NGINX, j’aimerais revenir rapidement sur le fonctionnement général de la mise en cache du contenu, afin que nous partions tous sur les mêmes bases et disposions des mêmes informations essentielles.

2:35 Principes de base

Le principe de base de la mise en cache du contenu consiste à décharger les serveurs en amont des tâches répétitives. Lorsque le premier utilisateur demande un contenu sur le site web (représenté par l’icône et les lignes bleues), sa requête HTTP est transmise à NGINX, puis au serveur en amont représenté en gris sur la droite.

La réponse est renvoyée à l’utilisateur distant, mais si elle peut être mise en cache (nous verrons bientôt ce que cela signifie), NGINX en stocke une copie. Lorsqu’un autre utilisateur, représenté en orange, demande le même contenu, NGINX peut alors le lui fournir directement depuis son cache local plutôt que de transmettre la requête au serveur en amont.

Ce principe de base, qui consiste à stocker du contenu pouvant être mis en cache et qui ne change pas, est utilisé par votre navigateur web, par les CDN auxquels ont recours les sites que vous consultez, ainsi que par NGINX sur d’autres appareils. Celui-ci fonctionne comme un cache de proxy inverse et est généralement déployé dans le centre de données ou dans le cloud, à proximité des serveurs d’origine qui hébergent votre contenu web et vos applications web.

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

Le serveur d’origine indique si le contenu peut être mis en cache à l’aide d’un ou de plusieurs en-têtes de réponse HTTP bien connus et parfaitement compris. Bien entendu, les serveurs de cache peuvent choisir d’ignorer, de remplacer ou de modifier ce comportement. Mais pour comprendre la mise en cache configurée du contenu, il faut d’abord bien comprendre comment un serveur d’origine indique qu’un contenu peut être mis en cache, qu’il ne change pas et que la copie [mise en cache] a une durée de vie déterminée.

La mise en cache du contenu a commencé avec un simple en-tête de réponse HTTP appelé « Expires ». Le serveur d’origine fournissait du contenu et indiquait que celui-ci resterait valide jusqu’à la date spécifiée dans l’en-tête Expires. Cette méthode a rapidement été supplantée par une méthode plus efficace et plus souple : l’en-tête Cache-Control.

Expires est quelque peu fastidieux à utiliser et manque d’efficacité. Les dates doivent être correctement formatées et analysées, tandis que Cache-Control est beaucoup plus simple et adapté aux besoins et à la rapidité des caches de contenu. Cache-Control indique si le contenu est public ou privé et, s’il est public, définit une valeur max-age – le nombre de secondes pendant lesquelles il peut être mis en cache avant que le système 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 propre à NGINX ; seul NGINX le comprend. Il permet de remplacer le comportement des en-têtes ci-dessus et d’indiquer directement à NGINX la durée précise pendant laquelle un élément de contenu doit être mis en cache.

Dans certains cas, vous pouvez souhaiter que le navigateur web mette le contenu en cache pendant une longue période, tout en préférant que le cache du proxy (NGINX placé devant le serveur d’origine) ne le conserve que pendant une période plus courte, afin que les modifications soient prises en compte plus rapidement et transmises aux nouveaux clients, sans que les anciens clients ne redemandent inutilement le contenu.

Cependant, cette méthode peut également être mise en œuvre à l’aide des deux derniers en-têtes. Un serveur d’origine peut indiquer la date de dernière modification d’un contenu et déclarer ce que l’on appelle un 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 méthodes GET conditionnelles. Ils peuvent inclure un en-tête If-Modified-Since ou If-None-Match dans leur requête. Ce faisant, le client indique qu’il dispose d’une version du contenu mise en cache, qui a été modifiée pour la dernière fois à une date donnée ou qui possède un ETag particulier. Si la version la plus récente détenue par le serveur correspond à celle du client, le serveur répond simplement avec le code 304 Not Modified. Cette réponse rapide économise de la bande passante et permet au client de vérifier à sa convenance si la copie du contenu mise en cache est toujours valide.

Ces cinq en-têtes définissent, du point de vue d’un serveur d’origine, les modalités de mise en cache du contenu : sa validité, sa fraîcheur et, en ce qui concerne l’ETag, les caractéristiques du contenu lui-même.

7:46 Que met NGINX en cache ?

Les caches proxy tels que NGINX sont relativement libres d’interpréter le degré de rigueur avec lequel ils respecteront ces en-têtes. De toute évidence, ils ne devraient pas mettre en cache un contenu qui ne peut pas l’être, mais ils ne sont bien sûr aucunement tenus de mettre en cache un contenu si le serveur d’origine indique qu’il peut l’être.

Le comportement de base de NGINX consiste à mettre en cache toutes les requêtes GET et HEAD que le serveur d’origine indique comme pouvant être mises en cache, à condition que la réponse ne contienne aucun en-tête Set-Cookie. En effet, les en-têtes Set-Cookie contiennent généralement des données uniques propres à chaque requête et, par défaut, il ne serait pas approprié de mettre cette valeur en cache.

NGINX met en cache chaque ressource à l’aide d’une clé spécifique, appelée clé de cache. Toutes les requêtes qui génèrent la même clé de cache recevront la même ressource. Par défaut, le cache est associé à l’URL brute ou, dans la configuration, à la chaîne illustrée sur cette diapositive [$scheme$proxy_host$uri$is_args$args]. Lorsque NGINX met du contenu en cache, [la durée de validité] est définie (par ordre de priorité) par l’en-tête X-Accel-Expires s’il est présent, ou par l’en-tête Cache-Control, ou encore par l’ancien en-tête Expires.

Vous pouvez configurer NGINX pour masquer certains de ces en-têtes ou définir à la place une durée de mise en cache fixe, indépendamment de ce qu’indique le serveur d’origine. À titre de référence, RFC 2616 définit le comportement attendu d’un cache proxy vis-à-vis du protocole HTTP.

Cela vous donne donc un bref aperçu du caractère universel de la mise en cache et du comportement par défaut de NGINX, qui met en cache les contenus pouvant généralement l’être sans risque, afin d’accélérer votre site web et de réduire la charge sur vos serveurs d’origine.

9:55 NGINX en fonctionnement

Voyons maintenant rapidement NGINX en action. Il est vraiment très facile de configurer NGINX pour activer la mise en cache du contenu.

10:06 Configuration de NGINX

Il suffit de quelques lignes dans votre fichier de configuration NGINX : la première crée un cache sur le disque avec un ensemble de paramètres définissant l’organisation des fichiers, la durée d’expiration [des objets de ce cache] et la taille du cache. La seconde, 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é.

Ici, j’ai donc créé un cache appelé one ; sa taille en mémoire est de 10 Mo pour les métadonnées, mais l’espace disque disponible pour le contenu mis en cache est illimité. Le contenu est mis en cache, puis supprimé s’il est resté inactif pendant 60 minutes. Ce cache appelé one est utilisé par notre serveur par défaut. Ces deux [directives], proxy_cache_path et proxy_cache, suffisent à activer une mise en cache fiable et cohérente pour un serveur proxy dans NGINX.

11:14 Processus de mise en cache

Le processus suivi par NGINX lorsqu’il reçoit une requête et interroge un cache se déroule comme suit. Nous commençons par lire la requête (encadré en haut à gauche de cette diapositive), puis nous construisons la clé de cache à partir de l’URI brute et des autres paramètres qui serviront à identifier la ressource correspondant à cette requête. Nous vérifions ensuite le cache sur le disque en consultant les métadonnées en mémoire afin de déterminer si nous disposons d’une copie valide et à jour de la réponse à cette requête.

Si c’est le cas, il s’agit d’un succès de cache. NGINX peut alors répondre directement depuis le cache. Pour ce faire, il fournit le contenu stocké sur le disque exactement comme il fournit du contenu statique. Vous bénéficiez ainsi du niveau de performances, de fiabilité et d’évolutivité pour lequel NGINX a été conçu. Lorsque vous fournissez du contenu depuis le cache de contenu de NGINX, vous obtenez exactement le même niveau [de performances] qu’avec du contenu statique.

En revanche, lorsque nous vérifions le cache, il peut arriver que la ressource demandée ne s’y trouve pas. Cela signifie que le contenu n’est pas présent dans le cache, ou que celui-ci n’est plus à jour et doit être actualisé. Dans le cas le plus simple, nous demandons alors ce contenu au serveur d’origine, recevons la réponse et vérifions si elle peut être mise en cache.

Si c’est le cas, nous l’enregistrons progressivement sur le disque, comme le fait NGINX pour toute réponse volumineuse traitée en mode proxy. Une fois la réponse enregistrée sur le disque, nous la copions dans le cache et répondons directement depuis celui-ci. Cette approche pose notamment problème lorsque NGINX reçoit simultanément plusieurs requêtes portant sur le même contenu et qu’elles entraînent toutes un défaut de cache.

Normalement, NGINX transmettrait toutes ces requêtes au serveur d’origine, ce qui risquerait de le surcharger, en particulier lorsque la génération des réponses prend beaucoup de temps. C’est pourquoi vous pouvez utiliser un verrou de cache. La directive « proxy_cache_lock » garantit que, lorsqu’un contenu est en cours d’actualisation, 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 serait envoyée au serveur en amont, tandis que les autres requêtes portant sur le même contenu seraient mises en attente jusqu’à ce que la réponse ait été renvoyée et insérée dans le cache (toutes les requêtes pouvant alors être satisfaites), ou jusqu’à l’expiration du délai d’attente [défini par la directive proxy_cache_lock_timeout] : NGINX a attendu suffisamment longtemps que le contenu soit renvoyé par le serveur et, à ce stade, les requêtes mises en attente sont transmises au serveur d’origine.

Ainsi, proxy_cache_lock et le délai d’expiration vous offrent un contrôle efficace pour éviter que, sur un site très fréquenté recevant de nombreuses requêtes pour un même contenu, l’expiration de ce contenu dans le cache ne surcharge soudainement le serveur d’origine avec de multiples requêtes.

Le processus de mise en cache de NGINX comporte un autre élément qui ne s’intègre pas facilement à cet organigramme, car il concerne presque toutes ses étapes. Il s’agit de la fonctionnalité configurée à l’aide de la directive proxy_cache_use_stale. À tout moment, si l’une de ces étapes échoue pour une raison quelconque, par exemple si un délai d’attente expire pendant la mise à jour du contenu, si le serveur en amont renvoie une réponse incorrecte ou si un autre type d’erreur se produit, nous pouvons répondre directement à partir du cache, même si le contenu qui y est stocké est obsolète.

Il s’agit d’un outil particulièrement puissant lorsque vos serveurs en amont sont submergés par le trafic ou deviennent indisponibles en raison d’une opération de maintenance ou d’une erreur critique. Il permet à NGINX de 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 se limite pas au protocole 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 servent d’interface avec des API telles que FastCGI ou SCGI. NGINX peut s’en charger directement en tant que proxy, de manière très similaire au proxy HTTP.

NGINX peut utiliser ses techniques de mise en cache pour les proxys HTTP, les proxys FastCGI, les proxys uWSGI et les proxys SCGI. Tous fonctionnent à peu près de la même manière que le proxy HTTP, avec des caches stockés sur disque et des réponses envoyées directement, ce qui évite d’avoir à transmettre les requêtes à ces services en amont.

NGINX peut également s’interfacer avec un serveur memcached, ce qui constitue 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 alimenter memcached avec le contenu nécessaire. Cela peut constituer un autre outil utile, et il existe de nombreuses façons d’alimenter memcached depuis un site externe si nécessaire. Vous pouvez donc considérer cette méthode comme un moyen de préremplir un cache pour NGINX si cela répond à vos besoins métier.

17:10 Comment comprendre ce qui se passe

La mise en cache peut s’avérer très complexe si vous disposez d’une infrastructure étendue comportant plusieurs niveaux, dont certains mettent le contenu en cache et d’autres non, certains génèrent du contenu et d’autres non. Il peut alors être particulièrement difficile de comprendre ce qui se passe — notamment d’où provient le contenu — ainsi que de diagnostiquer et de résoudre les problèmes rencontrés. Avec NGINX, nous nous efforçons de vous simplifier au maximum la tâche.

17:38 Instrumentation du cache

Grâce à des outils de mesure sophistiqués, vous pouvez les piloter dynamiquement afin de déterminer la provenance du contenu, son emplacement dans le cache et son état au sein de celui-ci.

La première étape consiste à utiliser la variable $upstream_cache_status, qui est calculée pour chaque requête à laquelle NGINX a répondu, que la réponse provienne ou non du cache. Vous ajoutez ensuite systématiquement la valeur de cette variable à votre réponse à l’aide de la directive add_header. Par convention, cette valeur est placée dans un en-tête X-Cache-Status de la réponse. Elle peut prendre l’une de sept valeurs différentes, indiquant comment le contenu a été servi : s’il a contourné le cache, s’il provient d’une revalidation ou s’il a été trouvé dans le cache.

C’est la première étape pour comprendre d’où proviennent vos réponses. Sont-elles issues du cache NGINX local ou d’un serveur en amont ? Vous pouvez examiner cet en-tête de réponse de différentes manières, notamment depuis la ligne de commande à l’aide d’outils tels que curl, ou, très couramment, dans votre navigateur web à l’aide d’outils de débogage interactifs.

Bien entendu, vous ne souhaitez peut-être pas communiquer cette valeur à tous vos utilisateurs finaux. Il convient donc de choisir avec soin les cas dans lesquels vous l’insérez dans l’en-tête de la réponse.

19:08 Instrumentation du cache (suite)

Le langage de configuration de NGINX vous offre la souplesse nécessaire pour appliquer des règles de manière sélective. Cet exemple ne présente qu’une des nombreuses façons de procéder. Nous récupérons l’adresse distante et, s’il s’agit de localhost, nous plaçons $upstream_cache_status dans une variable temporaire ($cache_status). Enfin, lorsque nous renvoyons une réponse, nous y ajoutons la variable temporaire.

Ainsi, seules les requêtes provenant d’adresses IP spécifiques verront la valeur de la variable $upstream_cache_status. Vous pouvez également faire bien d’autres choses. Nous verrons bientôt comment le contenu est stocké sur le disque. Vous pouvez inclure dans la réponse la clé utilisée pour calculer l’emplacement sur le disque. Vous pouvez y ajouter toutes sortes de paramètres pour vous aider à diagnostiquer le fonctionnement du cache.

20:09 État du cache

NGINX Plus, notre version commerciale de NGINX, offre plusieurs fonctionnalités supplémentaires utiles pour des cas d’usage tels que la mise en cache. NGINX Plus est une version de NGINX bénéficiant d’un support commercial, développée par notre équipe d’ingénieurs à Moscou et soumise à une batterie complète de tests de non-régression afin de garantir son bon fonctionnement.

NGINX Plus comprend également plusieurs fonctionnalités destinées aux entreprises qui souhaitent utiliser NGINX comme proxy inverse et répartiteur de charge, notamment des fonctionnalités de répartition de charge, de contrôle de l’état de santé et de streaming vidéo avancé. Dans ce contexte, il propose aussi des fonctionnalités de suivi d’état étendu, de diagnostic amélioré et de visualisation de l’activité de NGINX.

[Note de l’éditeur – La diapositive ci-dessus et le paragraphe suivant ont été mis à jour afin de faire référence à l’API NGINX Plus, qui remplace le module d’état distinct initialement présenté ici et rend son utilisation obsolète.]

Pour voir une démonstration, rendez-vous sur demo.nginx.com/dashboard.html : vous y trouverez une page web affichant les données d’état publiées par NGINX Plus à l’aide de l’API NGINX Plus. Si vous exécutez la commande curl indiquée, vous verrez les données JSON brutes provenant directement du binaire NGINX Plus (elles sont ici transmises à l’utilitaire jq afin d’afficher chaque élément sur une ligne distincte avec une indentation hiérarchique).

Dans ces données JSON, vous trouverez des informations en temps réel sur l’état de chacun des caches de votre déploiement NGINX Plus. Associées à la variable $upstream_cache_status et aux autres moyens dont vous disposez pour instrumenter le cache, elles vous donnent une excellente vue d’ensemble de la manière dont NGINX met le contenu en cache et vous permettent d’examiner chaque requête en détail afin de déterminer si elle provient ou non du cache et de connaître son état actuel dans celui-ci.

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

Maintenant que nous avons vu comment examiner la mise en cache du contenu de l’extérieur, intéressons-nous à son fonctionnement interne. Comment fonctionne-t-elle au sein de NGINX ? Comme je l’ai indiqué précédemment, le cache de contenu de NGINX fonctionne de manière très similaire à la gestion des fichiers sur disque. Lorsque vous diffusez du contenu depuis notre cache, vous bénéficiez des mêmes performances, de la même fiabilité et des mêmes optimisations du système d’exploitation que lorsque vous diffusez du contenu statique — les performances qui font la renommée de NGINX.

22:40 Fonctionnement

Le cache de contenu est stocké sur disque dans un cache persistant. Nous travaillons de concert avec le système d’exploitation pour charger ce cache disque en mémoire, en indiquant au cache de pages du système d’exploitation quel contenu doit être conservé en mémoire. Ainsi, lorsque nous devons fournir du contenu depuis le cache, nous pouvons le faire extrêmement rapidement.

Les métadonnées du cache, notamment les informations sur son contenu et sa date d’expiration, sont stockées séparément dans une zone de mémoire partagée entre tous les processus NGINX et restent en permanence en mémoire. NGINX peut ainsi interroger et parcourir le cache extrêmement rapidement ; il n’accède au cache de pages que lorsqu’il doit récupérer la réponse et la transmettre à l’utilisateur final.

Nous verrons comment le contenu est stocké dans le cache, comment ce cache persistant est chargé dans les processus de travail NGINX vides au démarrage, certaines des opérations de maintenance que NGINX effectue automatiquement sur le cache et, pour finir, comment supprimer manuellement du contenu du cache dans certaines situations.

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

Rappelez-vous que le cache de contenu est déclaré à l’aide d’une directive appelée « proxy_cache_path ». Cette directive définit plusieurs paramètres : l’emplacement du cache dans 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, le cache sur le disque est de 40 Mo.

Pour comprendre où le contenu est stocké, il faut comprendre la clé de cache, c’est-à-dire l’identifiant unique que NGINX attribue à chaque ressource pouvant être mise en cache. Par défaut, cet identifiant est constitué à partir des paramètres de base de la requête : le schéma, l’en-tête Host، l’URI et les éventuels arguments de la chaîne de requête.

Mais vous pouvez l’étendre si vous le souhaitez, en utilisant par exemple des valeurs de cookies, des en-têtes d’authentification ou même des valeurs calculées lors de l’exécution. Vous souhaitez peut-être stocker des versions différentes pour les utilisateurs situés au Royaume-Uni et ceux situés aux États-Unis. Tout cela est possible en configurant la directive proxy_cache_key.

Lorsque NGINX traite une requête, il calcule la clé proxy_cache_key, puis génère une somme MD5 à partir de cette valeur. Vous pouvez reproduire cette opération à l’aide de l’exemple de ligne de commande présenté plus bas sur la diapositive. Nous prenons la clé de cache httplocalhost:8002/time.php et la transmettons à md5sum. Lorsque vous effectuez cette opération depuis le shell, veillez à ne pas transmettre également un caractère de nouvelle ligne.

Cela permet de calculer la valeur de hachage MD5 correspondant à ce contenu pouvant être mis en cache. NGINX utilise cette valeur de hachage pour déterminer l’emplacement sur le disque où ce contenu doit être stocké. Vous verrez dans proxy_cache_path que nous définissons un cache à deux niveaux, avec un répertoire dont le nom comporte un caractère, puis un autre dont le nom en comporte deux. Nous prélevons ces caractères à la fin de la chaîne pour créer un répertoire nommé 4 et un sous-répertoire nommé 9b, puis nous enregistrons le contenu du cache (ainsi que 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 afficher la clé de cache dans l’un des en-têtes de réponse, puis la transmettre à md5sum pour calculer le hachage correspondant à cette valeur. Vous pouvez ensuite examiner la valeur sur le disque pour vérifier qu’elle s’y trouve bien, ainsi que les en-têtes mis en cache par NGINX, afin de comprendre comment tous ces éléments s’articulent.

26:36 Chargement du cache depuis le disque

Maintenant que le contenu est stocké de manière persistante sur le disque, NGINX doit, au démarrage, le charger en mémoire – ou plutôt, il doit parcourir le cache sur disque, en extraire les métadonnées, puis charger celles-ci en mémoire dans le segment de mémoire partagée utilisé par chacun des processus de travail. Cette opération est effectuée par un processus appelé le « chargeur de cache ».

Un chargeur de cache est lancé au démarrage et ne s’exécute qu’une seule fois. Il charge les métadonnées depuis le disque par petits lots : 100 fichiers à la fois, pendant une durée maximale de 200 ms, avec une pause de 50 ms entre chaque lot. L’opération se répète jusqu’à ce que l’intégralité du cache ait été parcourue et que le segment de mémoire partagée soit rempli.

Le chargeur de cache s’arrête ensuite et n’a plus besoin de s’exécuter, sauf si NGINX est redémarré ou reconfiguré et que le segment de mémoire partagée doit être réinitialisé. Vous pouvez ajuster le fonctionnement du chargeur de cache, ce qui peut être utile si vous disposez de disques très rapides et que la charge est faible. Vous pouvez accélérer son exécution ou, au contraire, la ralentir légèrement si votre cache contient un très grand nombre de fichiers, que vos disques sont lents et que vous ne souhaitez pas que le chargeur de cache consomme trop de ressources processeur au démarrage de NGINX.

28:07 Gestion du cache disque

Une fois le cache chargé en mémoire et les fichiers stockés sur le disque, les fichiers mis en cache auxquels personne n’accède risquent d’y rester indéfiniment. NGINX les stocke la première fois qu’il les rencontre, mais si un fichier ne fait plus l’objet d’aucune requête, il restera simplement sur le disque jusqu’à ce qu’un processus vienne le supprimer.

Ce quelque chose est le gestionnaire de cache ; il s’exécute périodiquement pour purger du disque les fichiers qui n’ont pas été consultés depuis un certain temps. Il supprime également des fichiers si le cache est trop volumineux et dépasse la taille déclarée. Il les supprime en commençant par les moins récemment utilisés. Vous pouvez configurer cette opération à l’aide des paramètres de la proxy_cache_path [directive], comme pour le chargeur de cache :

• Par défaut, le délai inactive est de 10 minutes.
• Le paramètre « max-size » n’a pas de limite par défaut. Si vous imposez une limite « max-size » au cache, celui-ci peut parfois la dépasser. Toutefois, lorsque le gestionnaire de cache s’exécute, il supprime les fichiers les moins récemment utilisés afin de repasser sous cette limite.

29:22 Purge du contenu du disque

Enfin, il peut arriver que vous souhaitiez purger du contenu du disque. Vous devez alors trouver un fichier et le supprimer. C’est relativement facile si vous connaissez les techniques évoquées précédemment : passer la clé de cache dans md5sum ou simplement exécuter une commande grep récursive sur l’ensemble du système de fichiers afin d’identifier le ou les fichiers à supprimer.

Sinon, si vous utilisez NGINX Plus, vous pouvez recourir à la fonctionnalité de purge du cache intégrée à ce produit. Celle-ci permet d’utiliser un paramètre particulier de la requête ; en général, nous utilisons une méthode appelée « PURGE » pour indiquer qu’il s’agit d’une requête de purge du cache.

La purge est gérée par un gestionnaire NGINX Plus spécial qui examine l’URI et supprime du cache tous les fichiers correspondant à cet URI. L’URI peut être suivi d’un astérisque afin de servir de préfixe. Dans ce cas, nous allons utiliser la fonctionnalité de purge pour supprimer tous les fichiers servis depuis l’hôte localhost sur le port 8001, mais vous pouvez bien entendu également indiquer des sous-répertoires.

Quelle que soit la méthode utilisée, vous pouvez à tout moment supprimer en toute sécurité des fichiers du cache sur le disque, voire exécuter rm -rf sur l’ensemble du répertoire de cache. NGINX continuera de fonctionner sans interruption et de vérifier la présence des fichiers sur le disque. S’ils sont absents, cela entraîne un défaut de cache. NGINX récupère alors le contenu auprès du serveur d’origine et le stocke de nouveau dans le cache sur le disque. Vous pouvez donc supprimer des fichiers individuels du cache en toute sécurité, fiabilité et stabilité.

31:27 Contrôle de la mise en cache

Nous avons donc vu comment fonctionne la mise en cache, étudié son implémentation dans NGINX et examiné en détail la façon dont les fichiers sont stockés sur disque afin d’obtenir des performances comparables à celles du contenu statique. Voyons maintenant comment optimiser un peu plus la mise en cache.

Pour les sites simples, vous pouvez activer la mise en cache et, en règle générale, elle fera exactement ce qu’il faut pour continuer à vous offrir le niveau de performances et le comportement du cache souhaités. Mais il est toujours possible d’apporter des optimisations, et il arrive souvent que le comportement par défaut ne corresponde pas à celui que vous recherchez.

Peut-être que vos serveurs d’origine ne définissent pas les bons en-têtes de réponse, ou peut-être souhaitez-vous remplacer directement dans NGINX les paramètres qu’ils spécifient. Il existe une multitude de façons de configurer NGINX afin d’affiner le fonctionnement de la mise en cache.

32:30 Mise en cache différée

Vous pouvez différer la mise en cache. Cette situation est très courante lorsque vous disposez d’un vaste corpus de contenus 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, tenter de mettre ce contenu en cache est souvent une perte de temps. La mise en cache différée vous permet de définir un seuil. Une version de ce contenu ne sera mise en cache que s’il a été demandé un certain nombre de fois. Tant que le seuil proxy_cache_min_uses n’est pas atteint, aucune version ne sera stockée dans le cache.

Cela vous permet de sélectionner plus finement le contenu à placer dans votre cache. Le cache lui-même est une ressource limitée, généralement par la quantité de mémoire disponible sur votre serveur, car vous devez veiller à ce qu’il soit chargé en mémoire autant que possible. Il est donc souvent préférable de limiter certains types de contenu et de ne mettre en cache que les requêtes les plus fréquentes.

La revalidation du cache est une fonctionnalité récemment ajoutée à NGINX Open Source et NGINX Plus. Elle modifie la fonctionnalité If-Modified-Since afin que, lorsque NGINX doit actualiser une valeur mise en cache, il n’effectue pas une simple requête GET pour récupérer une nouvelle version de ce contenu ; il effectue une requête GET conditionnelle en indiquant : « Je dispose d’une version en cache qui a été modifiée à cette date et à cette heure précises. »

Le serveur d’origine peut répondre avec le code 304 « Non modifié », indiquant ainsi que la version dont vous disposez est toujours la plus récente. Cela permet d’économiser de la bande passante en amont : le serveur d’origine n’a pas à renvoyer du contenu qui n’a pas changé, ce qui peut également réduire les écritures sur disque. NGINX n’a pas à transférer ce contenu sur le disque, puis à le mettre en place en remplaçant l’ancienne version.

34:45 Contrôle de la durée de mise en cache

Vous pouvez contrôler avec précision la durée de mise en cache du contenu. Très souvent, le serveur d’origine fournit le contenu avec des en-têtes de cache adaptés aux navigateurs : une mise en cache à long terme assortie de requêtes relativement fréquentes pour actualiser le contenu. Toutefois, vous souhaiterez peut-être que le proxy NGINX placé directement devant votre serveur d’origine actualise les fichiers un peu plus souvent afin de prendre en compte les modifications plus rapidement.

La charge augmente considérablement si vous réduisez le délai d’expiration du cache des navigateurs de 60 secondes à 10 secondes, mais elle n’augmente que très légèrement si vous réduisez celui du cache de NGINX de 60 secondes à 10 secondes. Pour chaque requête, cela ajoutera cinq requêtes supplémentaires par minute à vos serveurs d’origine, tandis que pour les clients distants, tout dépend du nombre de clients ayant des éléments similaires actifs sur votre site.

Vous pouvez donc passer outre la logique et les directives de votre serveur d’origine. Vous pouvez masquer certains en-têtes ou demander à NGINX de les ignorer : X-Accel-Expires, Cache-Control ou Expires. Vous pouvez également définir une durée de mise en cache par défaut à l’aide de la directive proxy_cache_valid dans votre configuration NGINX.

36:18 Mettre en cache / Ne pas mettre en cache

Il peut arriver que vous ne souhaitiez pas mettre en cache un contenu que le serveur d’origine indique comme pouvant l’être, ou que vous vouliez vous assurer de contourner la version du contenu stockée dans NGINX. Les directives « proxy_cache_bypass » et « proxy_no_cache » vous offrent ce niveau de contrôle.

Vous pouvez les utiliser comme raccourci pour indiquer que, si l’un des en-têtes de requête d’un ensemble donné est défini, par exemple l’en-tête d’autorisation HTTP, ou si un paramètre de requête est présent, vous souhaitez contourner le cache, soit pour mettre automatiquement à jour le cache dans NGINX, soit pour l’ignorer complètement et toujours récupérer le contenu depuis le serveur d’origine.

En général, ces directives sont utilisées pour prendre des décisions de mise en cache assez complexes, en définissant des règles précises selon les valeurs des cookies et des en-têtes d’autorisation afin de déterminer ce qui doit être mis en cache, ce qui doit toujours être récupéré depuis le serveur d’origine et ce qui ne doit jamais être stocké dans le cache NGINX.

37:25 Plusieurs caches

Enfin, pour les déploiements à très grande échelle, vous pourriez envisager d’utiliser plusieurs caches au sein d’une même instance NGINX, et ce, pour plusieurs raisons. Vous pourriez appliquer différentes politiques de cache aux différents locataires de votre proxy NGINX, selon la nature de leur site et l’importance de ses performances, voire selon l’offre particulière souscrite par chaque locataire dans le cadre d’un hébergement mutualisé.

Ou bien, l’hôte NGINX peut comporter plusieurs disques, auquel cas il est plus efficace de déployer un cache distinct sur chacun d’eux. La règle d’or consiste à réduire au minimum le nombre de copies d’un disque à l’autre. Pour ce faire, vous pouvez associer un cache à chaque disque et placer sur le disque approprié le fichier temporaire de chaque proxy qui utilise ce cache.

Le fonctionnement standard est le suivant : lorsque NGINX reçoit du contenu d’un proxy en amont, il l’écrit progressivement sur le disque, sauf si ce contenu est suffisamment petit pour tenir en mémoire. Une fois le contenu écrit sur le disque, NGINX le déplace dans le cache. Cette opération est infiniment plus efficace si l’emplacement des fichiers temporaires (le disque sur lequel ils sont stockés) se trouve sur le même disque que le cache.

39:07 Récapitulatif rapide – Pourquoi utiliser le cache ?

Nous avons donc parlé de la mise en cache, des méthodes utilisées par NGINX, de leur mise en œuvre dans NGINX et des différentes façons d’en ajuster les paramètres. Alors que nous approchons de la fin, faisons un rapide récapitulatif pour nous rappeler pourquoi il est utile de mettre du contenu en cache. NGINX est déployé sur 114 millions de sites web dans le monde, et nombre de ces utilisateurs choisissent NGINX pour ses capacités d’accélération web et de mise en cache du contenu. [Note de la rédaction – Cette statistique était valable lors de la diffusion du webinaire en mai 2014.]

39:44 Pourquoi la vitesse de chargement des pages est-elle importante ?

Ces fonctionnalités améliorent la vitesse d’un site web – elles offrent aux utilisateurs finaux une meilleure expérience – et la vitesse de chargement des pages web est vraiment très importante. Depuis des années, les analystes étudient le comportement des utilisateurs et ont établi ce que l’on appelle communément la « règle des N secondes ». Il s’agit du temps qu’un utilisateur moyen est prêt à attendre qu’une page se charge et s’affiche avant de se lasser, de s’impatienter et de se tourner vers un autre site web, celui d’un concurrent.

À mesure que les normes se sont améliorées et que les attentes des utilisateurs ont augmenté, le temps qu’ils sont prêts à patienter n’a cessé de diminuer. En extrapolant cette tendance à l’aide de calculs quelque peu douteux, on pourrait en conclure que les utilisateurs auront un niveau de patience négatif aux alentours de 2016.

40:46 Google a changé les règles

Mais en réalité, la technologie nous a dépassés. Google l’a illustré de manière frappante il y a quelques années lors du lancement de Google Instant Search. Désormais, lorsque vous saisissez un terme dans le champ de recherche de Google, des résultats de recherche potentiels s’affichent avant même que vous ayez fini de taper. Cela témoigne de l’évolution considérable des attentes sur 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 comme les pages d’un livre que l’on tourne » : aussi rapidement, naturellement et fluidement.

41:28 Le coût des mauvaises performances

Si vous n’atteignez pas ce niveau de performance, les indicateurs clés de performance (KPI) associés à votre site web ou à votre service en ligne peuvent être fortement affectés. Prenons le taux de clics sur les annonces : Google a constaté une baisse de 20 % lorsque le chargement de ses pages de recherche prenait une demi-seconde de plus. Il en va de même pour le chiffre d’affaires : afin d’étudier l’effet de la lenteur des pages web, Amazon a volontairement augmenté leur temps de chargement par paliers de 100 ms et constaté que le chiffre d’affaires généré par les clients concernés diminuait généralement de 1 % pour chaque augmentation de 100 ms.

De nombreux autres analystes, sites web et chercheurs ont constaté des effets similaires sur les indicateurs d’un site web, qu’il s’agisse du temps passé sur une page, du taux de rebond, etc. Plus récemment, Google a commencé à prendre en compte la vitesse de chargement des pages dans le calcul de leur classement dans les résultats de recherche. Le délai avant réception du premier octet semble être déterminant. Plus ce premier octet met de temps à arriver lors du chargement d’une page, plus le classement de celle-ci est pénalisé. Un site web peut ainsi ne même pas être consulté parce qu’il apparaît à la troisième, quatrième ou cinquième page des résultats de recherche Google.

43:00 La mise en cache NGINX vous permet de

Les fonctionnalités de mise en cache de NGINX vous permettent d’améliorer l’expérience utilisateur en réduisant le délai avant le 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 intègre un serveur web d’origine ainsi qu’une passerelle directe vers des API telles que FastCGI. NGINX Plus permet également de mettre en place un équilibreur de charge sophistiqué, adapté aux entreprises, ainsi qu’un contrôleur de mise à disposition d’applications. Vous pouvez ainsi regrouper plusieurs composants réseau distincts de votre infrastructure web en un seul composant – NGINX ou NGINX Plus – afin de bénéficier de solutions plus fiables, plus faciles à déboguer et plus rapides.

NGINX vous permet d’augmenter la capacité des serveurs en déchargeant les serveurs en amont des tâches répétitives. En fait, même pour du contenu qui semble ne pas pouvoir être mis en cache (la page d’accueil d’un site de blogs, par exemple), il peut être utile de le mettre en cache ne serait-ce qu’une seconde sur le proxy NGINX.

Lorsque cent utilisateurs demandent le même contenu au cours de la même seconde, NGINX réduit le tout à une seule requête adressée au serveur d’origine, puis fournit le contenu à ces utilisateurs depuis son cache, en garantissant qu’il ne date jamais de plus d’une seconde. C’est souvent largement suffisant pour un blog ou un site web similaire, tout en améliorant considérablement les performances, tant en réduisant la charge sur les serveurs en amont que les coûts liés à la gestion et au déploiement d’une capacité suffisante.

Enfin, n’oubliez pas l’un des usages stratégiques de NGINX : vous protéger contre les défaillances des serveurs en amont grâce à la fonctionnalité « use stale » du cache proxy. S’ils sont lents, renvoient des erreurs ou rencontrent un quelconque problème, NGINX peut alors se rabattre sur la version locale du contenu mise en cache et continuer à l’utiliser jusqu’à ce que vos serveurs en amont soient de nouveau opérationnels.

45:21 Conclusion

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. [Note de la rédaction – Cette statistique était valable lors de la diffusion du webinaire en mai 2014 ; consultez la valeur actuelle ici.] Pour découvrir davantage de solutions et obtenir plus de détails, consultez les blogs et les fiches de présentation des fonctionnalités sur nginx.com, qui décrivent les capacités de NGINX et de NGINX Plus. Consultez également notre liste des webinaires, qui présente non seulement les prochains webinaires, mais aussi ceux d’événements précédents de cette série, qui seront bientôt ajoutés.

Et si vous souhaitez explorer davantage ces fonctionnalités, vous trouverez bien sûr de la documentation et des solutions sur nginx.org et nginx.com, mais rien ne vaut le fait de télécharger le produit et de l’essayer. Le produit open source est disponible sur nginx.org, tandis que le produit commercial avec support, qui offre des fonctionnalités supplémentaires d’équilibrage de charge, de mise à disposition d’applications et de gestion, ainsi qu’une plus grande facilité d’utilisation, est disponible sur nginx.com.

Merci à toutes et à tous pour le temps et l’attention que vous m’avez accordés. J’espère que cette présentation et cette démonstration de la mise en cache de contenu dans NGINX auront été utiles et instructives pour nombre d’entre vous.

Questions-réponses

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

47:20 Requêtes de plages d’octets

Nous avons une question concernant les requêtes de plage d’octets. Celles-ci sont utilisées lorsqu’un client demande un contenu, mais n’en a besoin que d’une partie. Prenons l’exemple d’un fichier vidéo dont le client ne souhaite récupérer qu’un extrait. Il peut aussi s’agir, très souvent, d’un fichier PDF : l’utilisateur a lu les en-têtes contenant un index du fichier PDF, et le client souhaite uniquement télécharger un ensemble précis de pages. Comment cela fonctionne-t-il dans le cache de contenu de NGINX ?

Le processus est le suivant. Lorsque NGINX reçoit une requête de plage d’octets pour une ressource et que l’intégralité de cette ressource se trouve déjà dans le cache, NGINX renvoie depuis le cache la plage d’octets demandée par le client. Si cette ressource ne se trouve pas dans le cache, NGINX demande l’intégralité de la ressource au serveur en amont et la stocke dans le cache. À l’heure actuelle, NGINX ne tient alors pas compte de la requête de plage d’octets et renvoie l’intégralité de la ressource au client. Dans la plupart des cas, ce comportement est acceptable.

Par exemple, si un client télécharge un document PDF, sa première requête portera de toute façon sur l’intégralité du document. Ce n’est que si ce document est diffusé en continu que le client interrompt la connexion et commence à envoyer des requêtes portant sur des plages d’octets. Ainsi, pour le contenu mis en cache, NGINX respecte les requêtes portant sur des plages d’octets. Pour le contenu non mis en cache, NGINX récupère l’intégralité du contenu auprès du serveur en amont et la renvoie au client dans son intégralité pour cette requête.

49:13 Revalidation du cache proxy

Cette question concerne la fonctionnalité de revalidation du cache du proxy. Cette fonctionnalité permet à NGINX d’effectuer une requête conditionnelle GET auprès du serveur en amont afin de vérifier si le contenu a changé. La question est la suivante :

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

La réponse est qu’il vérifie uniquement la date If-Modified-Since du contenu. En pratique, il est généralement recommandé de toujours inclure If-Modified-Since dans vos réponses et de considérer les ETag comme facultatifs, car ils ne sont pas pris en charge de manière aussi cohérente ni aussi répandue que la date de « dernière modification » que vous indiquerez dans la réponse.

50:07 Répartition du cache sur des disques de même capacité

Est-il possible pour NGINX de répartir la charge de mise en cache d’un même site entre plusieurs disques identiques afin d’obtenir des performances optimales ?

Oui, c’est possible, mais cela demande un peu de travail. Le scénario classique consiste à déployer plusieurs disques sans RAID, puis des caches distincts, chacun étant associé à un disque. Cela nécessite une configuration supplémentaire et un partitionnement du trafic. Si vous avez besoin d’aide pour cette configuration, contactez notre communauté afin que nous puissions y traiter votre demande spécifique. Si vous utilisez NGINX Plus, contactez notre équipe d’assistance, qui se fera un plaisir de vous aider.

50:50 « Vary » en-tête

NGINX prend-il en compte l’en-tête « Vary » pour déterminer si une requête aboutit ou non à une correspondance dans le cache ?

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

51:25 Primitives de mise en cache

Tous les mécanismes et directives de mise en cache sont-ils bien respectés ?

En règle générale, oui. Il existe quelques cas limites, notamment les en-têtes « Vary », qui ne sont pas pris en compte. Dans de nombreux cas, les différents caches disposent d’une certaine marge d’interprétation quant aux exigences de la RFC. Dans la mesure du possible, nous avons privilégié 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 tous deux mis en cache ?

Oui. Si vous recevez une réponse provenant du cache, les en-têtes sont mis en cache au même titre que le corps de la réponse.

52:13 « *‑Encoding » En-têtes

Les valeurs des en-têtes sont mises en cache au même titre que le corps de la réponse, donc… je serais assez surpris que NGINX ne fonctionne pas correctement avec les différentes combinaisons de « Transfer-Encoding ». « Accept-Encoding » est souvent géré au moyen d’un en-tête « Vary » ; les remarques précédentes sur la nécessité d’inclure les en-têtes « Vary » dans votre clé de cache s’appliquent donc ici (dans le cas des clients qui ne prennent pas cela en charge).

52:56 SPDY

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

Absolument. Vous pouvez le considérer comme un proxy frontal pour NGINX, même si, en pratique, il est très, très étroitement intégré au cœur de NGINX. Oui, SPDY prend en charge la mise en cache.

53:15 Vary En-tête, deuxième manche

Voici une autre question concernant l’en-tête Vary. Pour confirmer, si vous utilisez des réponses avec l’en-tête Vary et des fichiers gzip, consultez certaines discussions sur Trac ou sur notre site communautaire pour trouver des solutions. L’approche la plus courante consiste à intégrer l’en-tête Vary dans la clé de cache.

53:45 PageSpeed

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

C’est une question que vous devriez poser aux 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. Ils sont proposés sous forme de service ; vous disposez donc d’un contrôle plus limité sur la manière dont le contenu est mis en cache et sur sa durée de conservation, mais ils constituent un outil extrêmement efficace pour rapprocher le contenu des utilisateurs finaux. NGINX est un outil très performant pour accélérer les applications web, et il est très courant de déployer les deux conjointement. Quant aux caches autonomes tels que Varnish, il s’agit là encore de technologies très performantes qui fonctionnent, à bien des égards, de manière similaire à NGINX. L’un des avantages de NGINX est qu’il réunit au sein d’une solution unique la diffusion de contenu depuis le serveur d’origine, les passerelles applicatives, la mise en cache et l’équilibrage de charge. Vous bénéficiez ainsi d’une infrastructure plus simple et plus intégrée, plus facile à déployer et à gérer, ainsi qu’à déboguer et à diagnostiquer en cas de problème.

Pour regarder le webinaire sur lequel repose cet article, cliquez ici.

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

À propos de l’auteur

Owen GarrettDirecteur senior de la gestion des produits

Autres articles de Owen Garrett