Fonctionnalité de NGINX Plus : mise en cache

L’un des cas d’utilisation les plus populaires de NGINX Plus est le cache de contenu, à la fois pour accélérer les serveurs d’origine locaux et pour créer des serveurs périphériques pour les réseaux de diffusion de contenu (CDN). La mise en cache peut réduire la charge sur vos serveurs d’origine par un facteur considérable, en fonction de la possibilité de mise en cache de votre contenu et du profil du trafic des utilisateurs.

NGINX Plus peut mettre en cache le contenu récupéré des serveurs HTTP en amont et les réponses renvoyées par les services FastCGI, SCGI et uwsgi.

NGINX Plus étend les capacités de mise en cache de contenu de NGINX Open Source en ajoutant la prise en charge de la purge du cache et une visualisation plus riche de l’état du cache sur le tableau de bord de surveillance de l’activité en direct :

état du cache R7

Pourquoi utiliser la mise en cache du contenu ?

La mise en cache du contenu améliore les temps de chargement des pages web, réduit la charge sur vos serveurs en amont et améliore la disponibilité en utilisant le contenu mis en cache comme sauvegarde en cas de défaillance de vos serveurs d’origine :

  • Amélioration des performances du site : NGINX Plus sert les contenus mis en cache de tous types à la même vitesse que les contenus statiques, ce qui se traduit par une latence réduite et un site web plus réactif.
  • Capacités accrues : NGINX Plus décharge vos serveurs d’origine des tâches répétitives, libérant ainsi de la capacité pour servir plus d’utilisateurs et exécuter plus d’applications.
  • Une plus grande disponibilité : NGINX Plus protège vos utilisateurs des erreurs catastrophiques en servant le contenu mis en cache (même s’il est périmé) lorsque les serveurs d’origine sont en panne.

NGINX Plus et NGINX fournissent une solution consolidée pour votre infrastructure web, réunissant un serveur HTTP pour le contenu d’origine, des passerelles d’application pour FastCGI et d’autres protocoles, et un proxy HTTP pour les serveurs en amont. NGINX Plus ajoute un équilibrage de charge d’application de niveau entreprise, consolidant les équilibreurs de charge front-end dans votre infrastructure web.

En détail : mise en cache du contenu avec NGINX Plus

Le contenu mis en cache est stocké dans un cache persistant sur le disque et servi par NGINX Plus et NGINX exactement de la même manière que le contenu d’origine.

Pour activer la mise en cache du contenu, il convient d’inclure les directives proxy_cache_path et proxy_cache dans la configuration :

# Définir un emplacement de cache de contenu sur le disque
proxy_cache_path /tmp/cache keys_zone=mycache:10m inactive=60m;

server {
    listen 80;
    server_name localhost;
 
    location / {
        proxy_pass http://localhost:8080;
 
       #référencer le cache dans un emplacement qui utilise proxy_pass
       proxy_cache mycache;
    }
}

Par défaut, NGINX Plus et NGINX adoptent une approche sûre et prudente de la mise en cache du contenu. Ils mettent en cache le contenu récupéré par une requête GET ou HEAD, sans l’option Set-Cookie, et la durée de la mise en cache est définie par les en-têtes du serveur d’origine (X-Accel-Expires, Cache-Control, et Expires). NGINX Plus respecte les extensions Cache-Control définies dans la RFC 5861, stale-while-revalidate et stale-if-error.

Chacun de ces comportements peut être étendu et affiné à l’aide d’une série de directives. Pour une introduction complète, voir le Guide d’administration de NGINX Plus.

Instrumenter le cache

L’API de surveillance de l’activité en direct de NGINX Plus rapporte une série de statistiques que vous pouvez utiliser pour mesurer l’utilisation et l’efficacité de vos caches de contenu :

Exemple de données JSON provenant de l’API de surveillance de l’activité en direct

Les données JSON contiennent des informations complètes sur l’activité du cache.

Gestion des contenus périmés

Par défaut, NGINX Plus et NGINX servent le contenu mis en cache tant qu’il est valide. La validité est configurable ou peut être contrôlée par l’option Cache-Control après la période de validité, le contenu mis en cache est considéré comme périmé et doit être revalidé en vérifiant que le contenu mis en cache est toujours le même que celui trouvé sur le serveur d’origine.

Il se peut que le contenu périmé ne soit plus jamais demandé par un client, c’est pourquoi NGINX Plus et NGINX revalident le contenu périmé uniquement lorsqu’il est demandé par un client. Cela peut être effectué en arrière-plan, sans interrompre ou retarder la requête du client, en servant immédiatement le contenu périmé. Le contenu périmé est également servi lorsque le serveur d’origine n’est pas disponible, ce qui offre une grande disponibilité en cas de pic de charge ou d’interruptions prolongées du serveur d’origine.

Les conditions dans lesquelles NGINX et NGINX Plus servent le contenu périmé peuvent être configurées à l’aide de directives ou en honorant les valeurs trouvées dans les champs Cache-Control, stale-while-revalidate et stale-if-error du serveur d’origine.

Purger le contenu du cache

L’un des effets secondaires de la mise en cache du contenu est que les mises à jour du contenu sur le serveur d’origine ne se propagent pas nécessairement immédiatement au cache, ce qui signifie que les clients peuvent continuer à recevoir du contenu ancien pendant un certain temps. Si une opération de mise à jour modifie un certain nombre de ressources en même temps (par exemple, modification d’un fichier CSS et des images référencées), il est possible qu’un client reçoive un mélange de ressources périmées et de ressources actuelles, ce qui donne un aspect incohérent.

Avec la fonction de purge de cache de NGINX Plus, vous pouvez facilement résoudre ce problème. La fonction proxy_cache_purge vous permet de supprimer immédiatement les entrées du cache de contenu de NGINX Plus qui correspondent à une valeur configurée. Cette méthode est plus facilement déclenchée par une requête qui contient un en-tête HTTP personnalisé ou une méthode.

Par exemple, la configuration suivante identifie les demandes qui utilisent la méthode HTTP PURGE et supprime les URL correspondantes :

proxy_cache_path /tmp/cache keys_zone=mycache:10m levels=1:2 inactive=60s;

map $request_method $purge_method {
    PURGE 1;
    default 0;
}

server {
    listen 80;
    server_name www.example.com;

    location / {
        proxy_pass http://localhost:8002;
        proxy_cache mycache;

        proxy_cache_purge $purge_method;
    }
}

Vous pouvez envoyer des demandes de purge à l’aide de différents outils, tels que la commande curl dans l’exemple suivant :

$ curl -X PURGE -D – "http://www.example.com/*"
HTTP/1.1 204 No Content
Server: nginx/1.5.12
Date: Sat, 03 May 2014 16:33:04 GMT
Connection: keep-alive

Comme le montre cet exemple, vous pouvez purger un ensemble complet de ressources ayant une racine URL commune, en ajoutant le caractère générique astérisque (*) à l’URL.

Plus d’informations

NGINX Plus hérite de toutes les capacités de mise en cache de NGINX. Pour plus de détails, voir le Guide d’administration de NGINX Plus et la documentation de référence.

Étapes suivantes