NGINX étant un serveur web open source consolidé et performant qui accélère la diffusion de contenu et d’applications, améliore la sécurité et renforce la scalabilité. L’un des cas d’utilisation les plus courants de Nginx est le Cache de Contenu, qui est le moyen le plus efficace d’optimiser les performances d’un site web.
Lire aussi : 10 meilleurs outils de mise en cache open source pour Linux
Vous pouvez utiliser NGINX pour accélérer les serveurs d’origine locaux en le configurant pour mettre en cache les réponses des serveurs amont et également pour créer des serveurs de bord pour les réseaux de diffusion de contenu (CDN). NGINX alimente certains des plus grands CDN.
Lorsqu’il est configuré en tant que cache, NGINX va :
- mettre en cache du contenu statique et dynamique.
- améliorer les performances du contenu dynamique avec micro-mise en cache.
- servir du contenu obsolète tout en le révalidant en arrière-plan pour de meilleures performances.
- remplacer ou définir des en-têtes Cache-Control, et plus encore.
Dans cet article, vous apprendrez à configurer NGINX en tant que Cache de Contenu dans Linux pour que vos serveurs web fonctionnent de manière aussi efficace que possible.
Prérequis :
Vous devriez avoir NGINX installé sur votre serveur Linux, sinon suivez ces guides pour installer Nginx :
Mettre en cache le contenu statique sur Nginx
Le contenu statique est le contenu d’un site web qui reste le même (ne change pas) sur toutes les pages. Les exemples de contenu statique incluent des fichiers tels que des images, des vidéos, des documents ; des fichiers CSS et des fichiers JavaScript.
Si votre site web utilise beaucoup de contenu statique, vous pouvez optimiser ses performances en activant la mise en cache côté client où le navigateur stocke des copies du contenu statique pour un accès plus rapide.
La configuration d’exemple suivante est un bon point de départ, remplacez simplement www.example.com par l’URL de votre site web et apportez des modifications aux autres chemins si nécessaire.
server {
# substitute your web server's URL for www.example.com
server_name www.example.com;
root /var/www/example.com/htdocs;
index index.php;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri =404;
include fastcgi_params;
# substitute the socket, or address and port, of your WordPress server
fastcgi_pass unix:/var/run/php5-fpm.sock;
#fastcgi_pass 127.0.0.1:9000;
}
location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg
|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid
|midi|wav|bmp|rtf)$ {
expires max;
log_not_found off;
access_log off;
}
}
Mettre en cache le contenu dynamique sur Nginx
Nginx utilise un cache persistant basé sur un disque situé quelque part dans le système de fichiers local. Commencez donc par créer le répertoire de disque local pour stocker le contenu mis en cache.
# mkdir -p /var/cache/nginx
Ensuite, définissez la propriété appropriée sur le répertoire de cache. Il doit être détenu par l’utilisateur Nginx ( nginx ) et le groupe ( nginx ) comme suit.
# chown nginx:nginx /var/cache/nginx
Poursuivez maintenant pour voir comment activer le contenu dynamique sur Nginx dans la section ci-dessous.
Activer le cache FastCGI dans Nginx
FastCGI (ou FCGI) est un protocole largement utilisé pour l’interface des applications interactives telles que PHP avec des serveurs web tels que NGINX. Il s’agit d’une extension du CGI (Common Gateway Interface).
Le principal avantage de FCGI est qu’il gère plusieurs requêtes CGI dans un seul processus. Sans cela, le serveur web doit ouvrir un nouveau processus (qui doit être contrôlé, traiter une requête et se fermer) pour chaque demande de service d’un client.
Pour traiter les scripts PHP dans un déploiement de pile LEMP, NGINX utilise FPM (FastCGI Process Manager) ou PHP-FPM, une implémentation alternative populaire de PHP FastCGI. Une fois que le processus PHP-FPM est en cours d’exécution, NGINX est configuré pour transmettre les requêtes à celui-ci pour le traitement. Ainsi, NGINX peut également être configuré pour mettre en cache les réponses du serveur d’application en aval PHP-FPM.
Sous NGINX, le cache de contenu FastCGI est déclaré en utilisant une directive appelée fastcgi_cache_path dans le contexte http{} de niveau supérieur, dans la structure de configuration de NGINX. Vous pouvez également ajouter la directive fastcgi_cache_key qui définit une clé (identifiant de requête) pour la mise en cache.
De plus, pour lire l’état de la cache en amont, ajoutez la directive add_header X-Cache-Status dans le contexte http{} – cela est utile à des fins de débogage.
En supposant que le fichier de configuration du bloc serveur de votre site se trouve dans /etc/nginx/conf.d/testapp.conf ou /etc/nginx/sites-available/testapp.conf (sous Ubuntu et ses dérivés), ouvrez le fichier en édition et ajoutez les lignes suivantes en haut du fichier.
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=CACHEZONE:10m; inactive=60m max_size=40m; fastcgi_cache_key "$scheme$request_method$host$request_uri"; add_header X-Cache $upstream_cache_status;
La directive fastcgi_cache_path spécifie le nombre de paramètres qui sont :
- /var/cache/nginx – le chemin du répertoire sur le disque local pour la cache.
- levels – définit les niveaux de hiérarchie d’une cache, il configure une hiérarchie de répertoires à deux niveaux sous /var/cache/nginx.
- keys_zone (nom:taille) – permet la création d’une zone de mémoire partagée où toutes les clés actives et les informations sur les données (méta) sont stockées. Notez que le stockage des clés en mémoire accélère le processus de vérification, en permettant à NGINX de déterminer plus facilement s’il s’agit d’un MISS ou d’un HIT, sans vérifier l’état sur le disque.
- inactive – spécifie la durée après laquelle les données mises en cache et non consultées pendant la période spécifiée sont supprimées de la cache indépendamment de leur fraîcheur. Une valeur de 60m dans notre exemple de configuration signifie que les fichiers non consultés après 60 seront supprimés de la cache.
- max_size – spécifie la taille maximale du cache. Il existe d’autres paramètres que vous pouvez utiliser ici (consultez la documentation de NGINX pour plus d’informations).
Les variables dans la directive fastcgi_cache_key sont décrites ci-dessous.
NGINX les utilise pour calculer la clé (identifiant) d’une requête. Il est important que pour envoyer une réponse mise en cache au client, la requête doit avoir la même clé qu’une réponse mise en cache.
- $scheme – schéma de la requête, HTTP ou HTTPS.
- $request_method – méthode de la requête, généralement « GET » ou « POST ».
- $host – cela peut être le nom d’hôte de la ligne de requête, ou le nom d’hôte du champ d’en-tête de requête « Host », ou le nom de serveur correspondant à une requête, dans l’ordre de priorité.
- $request_uri – signifie l’URI de requête originale complète (avec les arguments).
Aussi, la variable $upstream_cache_status dans la directive add_header X-Cache-Status est calculée pour chaque requête à laquelle NGINX répond, qu’il s’agisse d’un MISS (réponse non trouvée dans le cache, récupérée du serveur d’application) ou d’un HIT (réponse servie à partir du cache) ou l’une des autres valeurs prises en charge.
Ensuite, à l’intérieur de la directive location qui transmet les requêtes PHP à PHP-FPM, utilise les directives fastcgi_cache pour activer le cache que vous venez de définir ci-dessus.
Définissez également le temps de mise en cache pour différentes réponses en utilisant la directive fastcgi_cache_valid comme indiqué.
fastcgi_cache CACHEZONE; fastcgi_cache_valid 60m;
Si seule la durée de mise en cache est spécifiée comme dans notre cas, seules les réponses 200, 301 et 302 sont mises en cache. Mais vous pouvez également spécifier explicitement les réponses ou utiliser n’importe quelle (pour n’importe quel code de réponse) :
fastcgi_cache CACHEZONE; fastcgi_cache_valid 200 301 203 60m; fastcgi_cache_valid 404 10m; OR fastcgi_cache CACHEZONE; fastcgi_cache_valid any 10m;
Ajustement fin des performances de mise en cache FastCGI sur Nginx
Pour définir le nombre minimum de fois qu’une requête avec la même clé doit être effectuée avant que la réponse ne soit mise en cache, incluez la directive fastcgi_cache_min_uses, soit dans le contexte http{}, soit dans le contexte server{}, soit dans le contexte location{}.
fastcgi_cache_min_uses 3
Pour activer la révalidation des éléments de cache expirés à l’aide de requêtes conditionnelles avec les champs d’en-tête « If-Modified-Since » et « If-None-Match« , ajoutez la directive fastcgi_cache_revalidate, dans le contexte http{}, server{} ou location{}.
fastcgi_cache_revalidate on;
Vous pouvez également demander à NGINX de fournir le contenu mis en cache lorsque le serveur d’origine ou le serveur FCGI est hors service, en utilisant la directive proxy_cache_use_stale, dans la directive de localisation.
Ce paramètre de configuration signifie que lorsque NGINX reçoit une erreur, un délai d’attente, et l’une des erreurs spécifiées du serveur amont et possède une version obsolète du fichier demandé dans le contenu mis en cache, il fournit le fichier obsolète.
proxy_cache_use_stale error timeout http_500;
Une autre directive utile pour ajuster les performances de mise en cache FCGI est fastcgi_cache_background_update qui fonctionne en conjonction avec la directive proxy_cache_use_stale. Lorsqu’elle est activée, elle indique à NGINX de servir du contenu obsolète lorsque les clients demandent un fichier qui a expiré ou qui est en cours de mise à jour depuis le serveur amont.
fastcgi_cache_background_update on;
La directive fastcgi_cache_lock est également utile pour l’optimisation des performances de mise en cache, car si plusieurs clients demandent le même contenu qui n’est pas dans le cache, NGINX ne transmettra que la première demande au serveur amont, mettra en cache la réponse puis servira les autres demandes des clients à partir du cache.
fastcgi_cache_lock on;
Après avoir apporté toutes les modifications ci-dessus dans le fichier de configuration NGINX, enregistrez-le et fermez-le. Vérifiez ensuite la structure de la configuration pour toute erreur de syntaxe avant de redémarrer le service NGINX.
# nginx -t # systemctl restart nginx
Ensuite, testez si le cache fonctionne correctement, essayez d’accéder à votre application web ou à votre site en utilisant la commande curl suivante (la première fois devrait indiquer un MISS, mais les demandes ultérieures devraient indiquer un HIT comme le montre la capture d’écran).
# curl -I http://testapp.tecmint.com
Voici une autre capture d’écran montrant NGINX servant des données obsolètes.
Ajout d’exceptions pour contourner le cache
Il est possible de définir des conditions selon lesquelles NGINX ne doit pas envoyer de réponses mises en cache aux clients, en utilisant la directive fastcgi_cache_bypass. Et pour indiquer à NGINX de ne pas mettre en cache du tout les réponses du serveur amont, utilisez fastcgi_no_cache.
Par exemple, si vous souhaitez que les requêtes POST et les URL avec une chaîne de requête aillent toujours vers PHP. Tout d’abord, déclarez une instruction if pour définir la condition comme suit.
set $skip_cache 0;
if ($request_method = POST) {
set $skip_cache 1;
}
Ensuite, activez l’exception ci-dessus dans la directive location qui transmet les requêtes PHP à PHP-FPM, en utilisant les directives fastcgi_cache_bypass et fastcgi_no_cache.
fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache;
Il existe de nombreuses autres parties de votre site pour lesquelles vous ne souhaitez peut-être pas activer la mise en cache du contenu. Voici un exemple de configuration NGINX pour améliorer les performances d’un site WordPress, fourni sur le blog nginx.com.
Pour l’utiliser, apportez des modifications (telles que le domaine, les chemins, les noms de fichiers, etc.) pour refléter ce qui existe dans votre environnement.
fastcgi_cache_path /var/run/NGINX-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
server {
server_name example.com www.example.com;
root /var/www/example.com;
index index.php;
access_log /var/log/NGINX/example.com.access.log;
error_log /var/log/NGINX/example.com.error.log;
set $skip_cache 0;
# POST requests and URLs with a query string should always go to PHP
if ($request_method = POST) {
set $skip_cache 1;
}
if ($query_string != "") {
set $skip_cache 1;
}
# Don't cache URIs containing the following segments
if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php |sitemap(_index)?.xml") {
set $skip_cache 1;
}
# Don't use the cache for logged-in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass |wordpress_no_cache|wordpress_logged_in") {
set $skip_cache 1;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri /index.php;
include fastcgi_params;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 60m;
}
location ~ /purge(/.*) {
fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
}
location ~* ^.+.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg |gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi |wav|bmp|rtf)$ {
access_log off;
log_not_found off;
expires max;
}
location = /robots.txt {
access_log off;
log_not_found off;
}
location ~ /. {
deny all;
access_log off;
log_not_found off;
}
}
Activation du cache proxy dans NGINX
NGINX prend également en charge la mise en cache des réponses d’autres serveurs mandataires (définis par la directive proxy_pass). Pour ce cas de test, nous utilisons NGINX comme mandataire inverse pour une application web Node.js, nous activerons donc NGINX en tant que cache pour l’application Node.js. Toutes les directives de configuration utilisées ici ont des significations similaires aux directives FastCGI de la section précédente, nous ne les expliquerons donc pas à nouveau.
Pour activer la mise en cache des réponses d’un serveur mandataire, incluez la directive proxy_cache_path dans le contexte http{} de niveau supérieur. Pour spécifier comment les requêtes sont mises en cache, vous pouvez également ajouter la directive proxy_cache_key comme suit.
proxy_cache_path /var/cache/nginx app1 keys_zone=PROXYCACHE:100m inactive=60m max_size=500m; proxy_cache_key "$scheme$request_method$host$request_uri"; add_header X-Cache-Status $upstream_cache_status; proxy_cache_min_uses 3;
Ensuite, activez le cache dans la directive de localisation.
location / {
proxy_pass http://127.0.0.1:3000;
proxy_cache PROXYCACHE;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
}
Pour définir les conditions dans lesquelles NGINX ne renvoie pas le contenu mis en cache et ne met pas du tout en cache une réponse du serveur amont, incluez les directives proxy_cache_bypass et proxy_no_cache.
proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment; proxy_no_cache $http_pragma $http_authorization;
Optimisation des performances du cache mandataire
Les directives suivantes sont utiles pour l’optimisation des performances du cache mandataire. Elles ont également la même signification que les directives FastCGI.
proxy_cache_min_uses 3; proxy_cache_revalidate on; proxy_cache_use_stale error timeout updating http_500; proxy_cache_background_update on; proxy_cache_lock on;
Pour plus d’informations et de directives de configuration de mise en cache, consultez la documentation des deux principaux modules ngx_http_fastcgi_module et ngx_http_proxy_module.
Ressources supplémentaires : Mise en cache du contenu NGINX et Conseils pour améliorer les performances de WordPress.