Passer au contenu 
Cache NGINX gagne nettement en vitesse lorsque je configure de manière ciblée le cache « Open File » : celui-ci conserve les métadonnées des fichiers et les descripteurs en mémoire, ce qui évite des accès coûteux au système de fichiers. Avec des valeurs adaptées pour max, inactif, valide et min_uses j'optimise la diffusion de contenus statiques pour obtenir des temps de réponse rapides et réduire la charge d'E/S.
Points centraux
- Cache de métadonnées: enregistre l'existence, la taille, les horodatages et les identifiants plutôt que le contenu
- Dimensionnement: Équilibre entre l'utilisation de la mémoire vive, le taux de réussite et le taux de modification
- Contextes: idéal pour les images, le CSS et le JS ; éviter les chemins d'accès dynamiques
- Validation: Garantir l'actualité des données avec open_file_cache_valid
- Mesure: Vérifier les effets liés aux latences, aux E/S et au taux d'erreur
Ce que le cache des fichiers ouverts stocke réellement
Je participe au cache avec Ouvrir le fichier Le cache ne stocke pas le contenu des fichiers, mais des informations structurées : l'existence d'un fichier, sa taille, la date de sa dernière modification et le descripteur déjà ouvert. Ces informations sont disponibles en mémoire et raccourcissent le chemin menant à la réponse suivante. Chaque accès au disque dur évité réduit le Charge d'E/S et permet d'économiser du temps CPU, ce qui est particulièrement important lorsqu'il y a de nombreux petits fichiers. Selon la documentation NGINX, cette fonctionnalité prend en charge les descripteurs ouverts, les informations de répertoire et les erreurs de recherche. Cela accélère les analyses de répertoires et les chemins d'accès, qui, sans cela, devraient être relancés sur le disque à chaque requête.
J'utilise délibérément ce mécanisme pour les répertoires fréquemment consultés, comme les bibliothèques multimédias et les ressources de compilation. L'effet est particulièrement visible dans les projets comportant de nombreux Actifs, dans lesquelles le système de fichiers devient sinon un goulot d'étranglement. Le cache réduit sensiblement les appels système tels que stat(), open() et readdir(). Dans le même temps, le contrôle reste très fin, car je définis séparément la portée et la validité des entrées. Je maintiens ainsi les données à jour sans perdre l’avantage de la mise en cache.
Quand le cache des fichiers ouverts est-il utile ?
J'allume le Cache spécialement pour les livraisons statiques : images, CSS, JavaScript, polices et téléchargements. Je l'évite dans les zones dynamiques telles que les pages de connexion, les paniers d'achat ou les parcours personnalisés, où d'autres règles s'appliquent. WordPress et les interfaces frontales « headless » en tirent un grand bénéfice, car les thèmes, les plugins et les bundles fournissent de nombreux fichiers. Plus les fichiers restent constants, plus la Taux de réussite des métadonnées. Lorsque j'effectue des déploiements très fréquemment, je raccourcis les intervalles de validation.
Le gain est particulièrement significatif pour la diffusion de contenu via des SSD locaux. Même avec des configurations SATA plus anciennes ou des montages NFS, je gagne du temps à chaque accès. Je veille à n'activer la mise en cache que dans les contextes pertinents (http, serveur ou emplacement). J'évite ainsi que des répertoires inappropriés ne monopolisent de l'espace de stockage. Une séparation claire garantit ici une configuration lisible et un fonctionnement fiable.
Une configuration de démarrage qui fonctionne
Je commence par une brève Base, puis continuez à mesurer et à ajuster de manière contrôlée. Ces valeurs donnent de bons résultats initiaux sur de nombreux hôtes et limitent les risques. Important : commencez par vérifier avec `nginx -t`, puis exécutez la commande `reload`. Je définis délibérément ces directives au niveau http, mais je peux, si nécessaire, les utiliser de manière plus ciblée dans le bloc location approprié. Cela me permet de trouver rapidement un bon équilibre entre la consommation de mémoire et Performance.
open_file_cache max=1000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors off;Avec « max », je limite le nombre maximal d'objets mis en cache. « inactive » supprime les entrées inutilisées après la durée choisie. « valid » contrôle la fréquence à laquelle NGINX vérifie à nouveau les métadonnées par rapport au système de fichiers. « min_uses » garantit que seuls les fichiers réellement utilisés sont stockés dans le cache. J'utilise les caches d'erreurs avec modération afin d'éviter les faux positifs inutiles.
Dimensionnement correct : max, inactive, min_uses
Je détermine la taille du cache en fonction de données réelles Données de charge plutôt que sur des suppositions. Combien de fichiers statiques est-ce que je récupère aux heures de pointe, et comment le trafic se répartit-il ? À mesure que le nombre de fichiers augmente, j'augmente la valeur « max » progressivement, généralement par incréments de 500 ou 1 000. Au début, je règle « inactive » sur une durée plutôt courte, jusqu'à ce que je puisse évaluer le comportement avec certitude. « min_uses » limite le bruit de fond, afin que les fichiers rarement utilisés ne bloquent pas la mémoire.
Pour les sites comportant un très grand nombre de ressources, je fixe souvent la valeur « max » entre 5 000 et 10 000. Pour les petits projets, une valeur comprise entre 500 et 1 500 suffit généralement. Je surveille le taux de réussite, la courbe de RAM des workers NGINX et la latence sur les ressources statiques. Ensuite, je continue à ajuster les paramètres « max » et « inactive » jusqu’à obtenir le bon équilibre. En parallèle, je surveille le côté des connexions et je redimensionne si nécessaire. Faire évoluer worker_connections, afin de ne pas saturer le système lors des pics de trafic.
Validation et actualité : open_file_cache_valid
Je définis avec valide, pendant combien de temps NGINX considère les métadonnées comme fiables. Dans de nombreux déploiements, j'opte pour une approche plutôt prudente, par exemple entre 15 et 30 secondes. Lorsque les modifications sont rares, je peux opter pour un intervalle nettement plus long, de l’ordre de 60 à 300 secondes. Cet intervalle influe sur la fréquence à laquelle NGINX revérifie les attributs des fichiers, mais pas sur la diffusion du contenu. Cela permet de préserver la Actualité élevé, sans que chaque requête doive passer par le disque.
J'évite les valeurs extrêmes, car les deux présentent des inconvénients. Des intervalles trop courts augmentent la charge des appels système. Des intervalles trop longs risquent de faire en sorte que NGINX conserve trop longtemps en mémoire des métadonnées obsolètes. Je me base sur la fréquence de modification des fichiers et sur les cycles de publication. Dès que le pipeline de publication est en place, j’ajuste la valeur de `valid` en fonction de ce rythme.
Mise en cache judicieuse des erreurs : open_file_cache_errors
Je peux résoudre rapidement des problèmes tels que „ Fichier introuvable “ mettre en mémoire tampon, afin d'éviter les requêtes erronées répétées. Cela vaut la peine en cas de 404 récurrentes sur des chemins connus mais inexistants. Je règle donc « errors » sur « on » de manière ponctuelle et maintiens « inactive » à un niveau modéré. En revanche, je reste prudent avec les fichiers potentiellement éphémères ayant un cycle de vie court. Cela me permet d’éviter que des fichiers temporaires états entraîner des faux négatifs.
Pour les cas génériques d'erreurs 404, je recommande plutôt un bloc « location » dédié avec des règles claires. Cela me permet de gérer les caches d'erreurs séparément du cache de fichiers habituel. Dans des répertoires multimédias bien organisés, les erreurs sont généralement rares. Cela permet d'économiser de l'espace de stockage et d'éviter toute confusion lors d'analyses ultérieures. Une séparation claire facilite ici le dépannage.
Synergies : sendfile, tampon, compression
Je combine le cache de fichiers ouverts avec sendfile en effet, les transferts de fichiers au niveau du noyau évitent d'avoir à les copier dans l'espace utilisateur. Pour les contenus statiques, cela réduit les changements de contexte et assure une diffusion plus fluide. Des tampons de sortie adaptés réduisent encore davantage les appels système et maintiennent un débit stable. Gzip ou Brotli compressent les ressources textuelles et réduisent ainsi la bande passante et la latence. Parallèlement, je configure la Processus « worker » de manière à ce qu'ils correspondent à la topologie du processeur.
J'étudie également les stratégies d'en-têtes pour la mise en cache côté client. Des durées « Cache-Control » longues sur des paquets immuables permettent de réduire les temps de aller-retour (RTT), tandis que je reste prudent avec les fichiers qui changent fréquemment. En combinaison avec les ETags ou la date « Last-Modified », je garantis des revalidations efficaces. C'est ainsi que le cache client, le cache de fichiers ouverts et la compression fonctionnent en synergie. Cela agit comme un multiplicateur pour une Temps de réponse.
Linux et le stockage : le rôle du matériel
Je tire le meilleur parti de Cache de fichiers, à condition que le stockage et la configuration du noyau soient adaptés. Des SSD plus rapides, des planificateurs d'E/S optimisés et suffisamment de mémoire vive pour le cache de pages apportent des gains immédiats. En revanche, une utilisation élevée des inodes et des systèmes de fichiers fragmentés font perdre du temps. Je surveille également le nombre de descripteurs ouverts et j'ajuste les limites du système. Ainsi, le système d'exploitation constitue une base efficace pour un fonctionnement rapide Accès.
Sur les hôtes de machines virtuelles, je tiens compte des effets d’overcommit et de « voisin bruyant ». Je vérifie si les latences NFS ou réseau réduisent l’efficacité du cache de fichiers ouverts. Les scénarios de conteneurs avec des systèmes de fichiers overlay se comportent également différemment selon la structure des couches. Je mesure donc la charge réelle en production, et pas seulement des tests sur des répertoires vides. Cela me permet de détecter rapidement les goulots d'étranglement et de réagir de manière ciblée.
Suivi et indicateurs : comment mesurer l'impact
Je mesure l'impact à travers Latence, les appels système, les temps d'attente d'E/S et les ressources des workers. Des outils tels que strace, perf, iostat et nginx-status m'aident à mettre en évidence cet effet. Je surveille le « Time-to-First-Byte » pour les routes statiques et je compare les situations de « hit » et de « miss ». Grâce aux journaux, j’identifie les chemins 404 récurrents ou les répertoires « chauds ». En parallèle, je vérifie le Limite du descripteur de fichier, afin que les handles ouverts ne soient pas bloqués aux limites des processus.
Je recueille des indicateurs avant et après la migration. Ensuite, j'ajuste les paramètres « max », « inactive » et « valid », puis je procède à une nouvelle mesure. Deux à trois itérations suffisent souvent pour atteindre une valeur cible précise. En cas de pics de trafic, je vérifie si les courbes de charge sont plus régulières. Ainsi, je ne me contente pas de preuves anecdotiques pour étayer les gains, mais je m'appuie sur des données claires chiffres.
Les pièges typiques et comment les éviter
J'active le Cache Pas de manière globale pour tout, mais uniquement là où cela apporte un avantage. Je soulage les points de terminaison dynamiques autrement, par exemple via les caches d'applications ou des stratégies de périphérie. Je ne choisis pas au hasard des valeurs max extrêmement élevées, car la mémoire vive finit par manquer. Des valeurs « inactive » trop longues maintiennent en mémoire des éléments obsolètes dont aucune requête n’a plus besoin. De même, des intervalles « valid » prématurés génèrent inutilement des appels système et réduisent l’avantage en termes de vitesse.
Je définis des directives pour chaque répertoire et je documente les responsabilités. Après chaque déploiement, je vérifie par échantillonnage que les fichiers importants sont à jour. Je formule clairement les messages d'erreur afin que les analyses des erreurs 404 ne se perdent pas dans le bruit de fond. Les avertissements dans le journal des erreurs font partie de mes contrôles réguliers. Grâce à une maintenance rigoureuse, le cache des fichiers ouverts reste fiable et efficacement.
Exemples concrets : petits sites vs grands sites
Je classe les configurations en fonction du nombre de fichiers, du trafic et de la fréquence des modifications, et j'en déduis Valeurs . Les petits projets nécessitent peu d’entrées, des périodes d’inactivité courtes et des périodes de validité modérées. Les sites de taille moyenne à grande ont recours à des valeurs maximales plus élevées et à des intervalles adaptés. Les déploiements fréquents justifient des périodes de validité plus courtes, tandis que les déploiements rares permettent des périodes plus longues. Le tableau présente des valeurs de départ types, que je vérifierai ultérieurement par des mesures.
| Configuration | Fichiers (environ) | max | inactif | valide | min_uses | Remarque |
|---|---|---|---|---|---|---|
| Petit site | 200–1.000 | 500–1.500 | 20-30s | 30 à 60 s | 2 | Économique démarrer, vérifier |
| Moyens | 1.000–10.000 | 2.000–6.000 | 30 à 60 s | 60 à 120 s | 2-3 | Trafic- Observer les pics |
| Grand | 10.000+ | 6.000–10.000 | 45 à 120 s | 120 à 300 s | 3+ | Mémoire vive et E/S limitées vérifier |
| Déploiements fréquents | variable | adapté | 20 à 45 s | 15 à 60 s | 2-3 | La fraîcheur avant tout Taux de réussite |
Liste de contrôle pour la mise en place
Je prépare un Plan Tout d'abord, je définis les répertoires dans lesquels la mise en cache des métadonnées est utile et j'exclus les zones dynamiques. Ensuite, je définis des valeurs de départ prudentes et je vérifie la configuration à l'aide de la commande `nginx -t`. Je redémarre NGINX, j'observe les latences et j'examine les journaux ainsi que les métriques système. Je procède ensuite à des ajustements progressifs des paramètres max, inactive, valid et min_uses. Pour finir, je documente les valeurs définitives pour chaque environnement et j'enregistre les modifications avec un numéro de version.
Je prévois une option de retour en arrière au cas où les effets ne seraient pas ceux escomptés. Pour les chemins 404 récurrents, je décide au cas par cas si je mets temporairement les erreurs en cache. Je définis les responsabilités : qui modifie les valeurs, qui effectue les mesures, qui valide les versions. Dans les déploiements comportant de nombreux supports, j'établis des benchmarks par rapport au trafic de pointe. Je procède ainsi de manière méthodique et obtiens des résultats durables Résultats.
Choisir correctement le champ d'application : http, serveur ou emplacement
J'active le cache « Open File » là où son efficacité est mesurable. Une activation globale au niveau HTTP est pratique, mais souvent trop générale. Il vaut mieux un Définition du champ d'application par serveur ou par site. Ainsi, les zones dynamiques ne sont pas affectées et les répertoires statiques en tirent pleinement parti. Je désactive le cache pour les routes API ou d'administration, je l'active pour les chemins d'accès aux ressources et je le configure sur mesure.
http {
# Par défaut : désactivé, afin que les zones dynamiques restent neutres
open_file_cache off;
server {
root /var/www/site;
# Ressources statiques avec leur propre profil
location ^~ /assets/ {
open_file_cache max=6000 inactive=60s;
open_file_cache_valid 120s;
open_file_cache_min_uses 2;
open_file_cache_errors off;
try_files $uri =404;
}
# Dynamique : aucun cache de fichiers ouvert nécessaire
location /api/ {
proxy_pass http://backend;
}
}
}Je commence par quelques lieux bien définis, puis j'élargis progressivement l'univers. Ainsi, les effets restent compréhensibles et j'évite les interactions indésirables entre les règles.
Architecture multiprocessus : la RAM et ses limites en ligne de mire
NGINX fonctionne avec plusieurs Workern, et chaque worker gère son propre cache de fichiers ouverts. Cela signifie que le nombre maximal d'entrées se multiplie par le nombre de workers. Avec quatre workers et un nombre maximal de 5 000, on peut potentiellement atteindre 20 000 entrées dans l'espace des processus. Je prévois donc de la mémoire vive par travailleur et observe les courbes réelles. Chaque entrée génère quelques centaines d'octets de métadonnées et de structures de gestion, auxquels s'ajoutent les coûts liés aux descripteurs ouverts.
Je présente également la Limites des descripteurs de fichiers adaptée (à l'échelle du système et pour le processus NGINX). Si la limite est insuffisante, les descripteurs ouverts peuvent échouer et le cache perd de son efficacité. Je vérifie la valeur de `ulimit -n` pour l'utilisateur NGINX et, si nécessaire, j'utilise `worker_rlimit_nofile` afin d'amortir les pics en toute sécurité. Je vérifie le nombre réel de fichiers ouverts à l'aide de `lsof` ou via les statistiques des processus, afin de ne pas me contenter d'une estimation, mais d'avoir une certitude.
Liens symboliques, alias et try_files : des détails qui font la différence
Dans la pratique, on rencontre souvent Liens symboliques, alias et try_files combinés. Je veille à utiliser correctement alias (avec la sémantique des barres obliques appropriée) et à éviter les pièges. Les cibles des liens symboliques peuvent changer d’une version à l’autre, alors que NGINX conserve encore les métadonnées en cache. C’est voulu, tant que l’intervalle « valid » est suffisamment court. Pour les chemins sensibles, j’ajoute une sécurité supplémentaire avec « disable_symlinks if_not_owner ».
location /media/ {
# : l'alias doit respecter le format du répertoire (barre oblique finale !)
alias /mnt/storage/media/;
disable_symlinks if_not_owner from=/mnt/storage;
open_file_cache max=8000 inactive=90s;
open_file_cache_valid 60s;
try_files $uri =404;
}Avec `try_files`, je définis des solutions de repli claires et j'évite les chaînes qui entraînent des recherches multiples. Des chemins cohérents (racine/alias) et une gestion des erreurs claire permettent de réduire les résultats négatifs inutiles dans le cache. Les recherches restent ainsi rapides et transparentes.
Déploiements sans redémarrage à froid : gérer la mise à jour
À l'adresse suivante : Temps de descente zéro- Lors des déploiements, je remplace souvent un lien symbolique (par exemple, current → releases/123). Le cache des fichiers ouverts conserve les anciennes métadonnées jusqu'à la prochaine validation. Je gère cela de manière ciblée : soit je définis une valeur plus courte pour `open_file_cache_valid` (par exemple 5 à 15 s) autour du déploiement, soit je redémarre NGINX après la bascule. Un rechargement lance de nouveaux workers qui construisent les nouvelles métadonnées, tandis que les anciens workers traitent les requêtes de manière propre. Ainsi, la mise à disposition reste stable et la fraîcheur haut.
Lorsque les ensembles d'éléments sont très volumineux, je peux ensuite identifier les chemins les plus sollicités se mettre en route (par exemple via un bref crawl), afin que les entrées les plus importantes soient mises en cache rapidement. Je veille toutefois à ce que ce processus reste léger, afin de ne pas générer artificiellement de pics d'E/S.
Options de système de fichiers et de montage : de petits réglages pour un grand effet
Je fais attention à noatime/nodiratime lors du montage de volumes locaux. Cela permet d'éviter des mises à jour inutiles de l'atime lors des accès et de réduire les E/S. Sur NFS, la stratégie de mise en cache des attributs (par exemple, actimeo) influence la apparente Actualité – je choisis des valeurs compatibles avec « valid » afin d’éviter toute incohérence. Pour les données de production, je mise sur des systèmes de fichiers éprouvés (tels que ext4 ou xfs) et je surveille de près les réserves d'inodes. Les volumes saturés ou fortement fragmentés font perdre du temps, indépendamment de NGINX.
Dans des conteneurs dotés de systèmes de fichiers « overlay », j'évalue l'impact du cache des fichiers ouverts en charge, et non en mode veille. La superposition peut alourdir les accès aux métadonnées ; c’est pourquoi je règle les paramètres « inactive » et « valid » de manière plutôt prudente et me concentre sur les « hotsets ».
Compression et variantes statiques : gzip_static, Brotli et Ranges
J'utilise, dans la mesure du possible, gzip_static (et, de la même manière, Brotli), afin de servir directement les fichiers pré-compressés. Le cache Open File met alors également à disposition les métadonnées pour les variantes .gz/.br ; min_uses filtre les formats rares et inhabituels. Les requêtes de plage (range requests) bénéficient de métadonnées stables (taille, mtime), associées à sendfile et à des réglages judicieux de tcp_nopush/tcp_nodelay.
location ~* \.(?:css|js|svg|json|txt)$ {
gzip_static on; # privilégier les fichiers .gz existants
sendfile on;
tcp_nopush on;
open_file_cache max=4000 inactive=45s;
open_file_cache_valid 90s;
open_file_cache_min_uses 2;
}Je veille à la cohérence entre l'ETag et la date de dernière modification. Cela permet aux clients de procéder efficacement à la revalidation, et NGINX a ainsi moins souvent besoin d'accéder en profondeur au système de fichiers. Le cache de fichiers ouverts fournit rapidement les métadonnées nécessaires à cet effet.
Analyse approfondie et dépannage : ce que je vérifie concrètement
- Appels système : à titre d'essai, j'applique strace à un worker (par exemple, -e trace=open,stat) et je compare la fréquence avant et après l'activation.
- Charge d'E/S : la commande `iostat -xz`, exécutée à intervalles réguliers, permet de vérifier si les temps d'attente et les profondeurs de file d'attente diminuent.
- Chems d'accès erronés : les fichiers journaux m'indiquent si des erreurs 404 récurrentes se produisent. Ces chemins peuvent faire l'objet d'une désactivation temporaire des erreurs – de manière ponctuelle.
- Limites FD : la commande « lsof -p | wc -l » m'indique un nombre impressionnant de descripteurs ouverts.
- Mémoire : je surveille le flux RSS par worker et je le mets en corrélation avec la valeur « max » et le taux de réussite des requêtes statiques.
Lorsque des latences inattendues apparaissent, je vérifie d'abord si « valid » est trop court (trop de réinitialisations) ou si « inactive » est trop long (fichiers obsolètes). Je retire les répertoires corrompus du cache et je refais la mesure. Cela me permet d'isoler rapidement les causes.
Aspects liés à la sécurité et frontières propres
Je sépare clair Je fais la distinction entre les chemins publics et internes, et je désactive l'auto-indexation. Pour les alias et les liens symboliques, j'utilise des variantes restrictives (if_not_owner) afin d'éviter tout parcours indésirable. Je n'active la mise en cache des erreurs que lorsque je comprends parfaitement le comportement. Dans les environnements multi-locataires, j’isole les caches par vHost afin d’éviter les chevauchements. Des limites clairement définies facilitent également le débogage, car elles me permettent de mieux identifier les effets par zone.
Étapes supplémentaires de réglage
Je regarde par-dessus le Cache de fichiers et j'ajuste les paramètres réseau et TLS. Les paramètres Keepalive, l'utilisation de HTTP/2 ou HTTP/3 et des délais d'expiration raisonnables ont une influence significative sur les latences globales. Pour les fichiers volumineux, je vérifie sendfile, aio et la taille des tampons de sortie. Je définis des limites raisonnables pour la taille des en-têtes et du corps des requêtes, afin que les requêtes aberrantes ne bloquent pas tout le système. De plus, je limite la journalisation de manière ciblée afin de réduire la surcharge à tiennent.
Côté application, je gère les caches statiques et dynamiques de manière à ce qu'ils n'interfèrent pas les uns avec les autres. Le versionnage des ressources à long terme par hachage réduit les revalidations et permet d'allonger la durée de vie des caches côté client. Pour les API, je définis des règles courtes et claires et je gère les fichiers statiques séparément. Je sépare les instances NGINX par cas d'utilisation lorsque l'isolation présente des avantages. Une configuration bien organisée permet de gagner du temps lors de l'exploitation et du dépannage.
En bref
Grâce à un placement judicieux Ouvert Grâce au cache de fichiers, je réduis les accès au système de fichiers, j'économise du temps CPU et je fournis les fichiers statiques plus rapidement. Je commence par des valeurs modérées, je mesure les effets réels, puis j'ajuste progressivement les paramètres max, inactive, valid et min_uses. Les répertoires statiques en bénéficient, tandis que j'exclue les points de terminaison dynamiques. En combinaison avec sendfile, l’optimisation des tampons, la compression et des limites système bien définies, j’améliore sensiblement les performances globales. NGINX devient ainsi un serveur fiable Base pour une livraison rapide et respectueuse des ressources.
