{"id":20898,"date":"2026-08-22T15:04:55","date_gmt":"2026-08-22T13:04:55","guid":{"rendered":"https:\/\/webhosting.de\/nginx-cache-optimierung-fenster\/"},"modified":"2026-08-22T15:04:55","modified_gmt":"2026-08-22T13:04:55","slug":"fenetre-doptimisation-du-cache-nginx","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/nginx-cache-optimierung-fenster\/","title":{"rendered":"Configurer au mieux le cache de fichiers ouverts NGINX : comment optimiser les performances de votre serveur"},"content":{"rendered":"<p><strong>Cache NGINX<\/strong> gagne nettement en vitesse lorsque je configure de mani\u00e8re cibl\u00e9e le cache \u00ab Open File \u00bb : celui-ci conserve les m\u00e9tadonn\u00e9es des fichiers et les descripteurs en m\u00e9moire, ce qui \u00e9vite des acc\u00e8s co\u00fbteux au syst\u00e8me de fichiers. Avec des valeurs adapt\u00e9es pour <strong>max<\/strong>, <strong>inactif<\/strong>, <strong>valide<\/strong> et <strong>min_uses<\/strong> j'optimise la diffusion de contenus statiques pour obtenir des temps de r\u00e9ponse rapides et r\u00e9duire la charge d'E\/S.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<ul>\n  <li><strong>Cache de m\u00e9tadonn\u00e9es<\/strong>: enregistre l'existence, la taille, les horodatages et les identifiants plut\u00f4t que le contenu<\/li>\n  <li><strong>Dimensionnement<\/strong>: \u00c9quilibre entre l'utilisation de la m\u00e9moire vive, le taux de r\u00e9ussite et le taux de modification<\/li>\n  <li><strong>Contextes<\/strong>: id\u00e9al pour les images, le CSS et le JS ; \u00e9viter les chemins d'acc\u00e8s dynamiques<\/li>\n  <li><strong>Validation<\/strong>: Garantir l'actualit\u00e9 des donn\u00e9es avec open_file_cache_valid<\/li>\n  <li><strong>Mesure<\/strong>: V\u00e9rifier les effets li\u00e9s aux latences, aux E\/S et au taux d'erreur<\/li>\n<\/ul>\n\n<h2>Ce que le cache des fichiers ouverts stocke r\u00e9ellement<\/h2>\n\n<p>Je participe au cache avec <strong>Ouvrir le fichier<\/strong> Le cache ne stocke pas le contenu des fichiers, mais des informations structur\u00e9es : l'existence d'un fichier, sa taille, la date de sa derni\u00e8re modification et le descripteur d\u00e9j\u00e0 ouvert. Ces informations sont disponibles en m\u00e9moire et raccourcissent le chemin menant \u00e0 la r\u00e9ponse suivante. Chaque acc\u00e8s au disque dur \u00e9vit\u00e9 r\u00e9duit le <strong>Charge d'E\/S<\/strong> et permet d'\u00e9conomiser du temps CPU, ce qui est particuli\u00e8rement important lorsqu'il y a de nombreux petits fichiers. Selon la documentation NGINX, cette fonctionnalit\u00e9 prend en charge les descripteurs ouverts, les informations de r\u00e9pertoire et les erreurs de recherche. Cela acc\u00e9l\u00e8re les analyses de r\u00e9pertoires et les chemins d'acc\u00e8s, qui, sans cela, devraient \u00eatre relanc\u00e9s sur le disque \u00e0 chaque requ\u00eate.<\/p>\n\n<p>J'utilise d\u00e9lib\u00e9r\u00e9ment ce m\u00e9canisme pour les r\u00e9pertoires fr\u00e9quemment consult\u00e9s, comme les biblioth\u00e8ques multim\u00e9dias et les ressources de compilation. L'effet est particuli\u00e8rement visible dans les projets comportant de nombreux <strong>Actifs<\/strong>, dans lesquelles le syst\u00e8me de fichiers devient sinon un goulot d'\u00e9tranglement. Le cache r\u00e9duit sensiblement les appels syst\u00e8me tels que stat(), open() et readdir(). Dans le m\u00eame temps, le contr\u00f4le reste tr\u00e8s fin, car je d\u00e9finis s\u00e9par\u00e9ment la port\u00e9e et la validit\u00e9 des entr\u00e9es. Je maintiens ainsi les donn\u00e9es \u00e0 jour sans perdre l\u2019avantage de la mise en cache.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/server-tuning-7234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quand le cache des fichiers ouverts est-il utile ?<\/h2>\n\n<p>J'allume le <strong>Cache<\/strong> sp\u00e9cialement pour les livraisons statiques : images, CSS, JavaScript, polices et t\u00e9l\u00e9chargements. Je l'\u00e9vite dans les zones dynamiques telles que les pages de connexion, les paniers d'achat ou les parcours personnalis\u00e9s, o\u00f9 d'autres r\u00e8gles s'appliquent. WordPress et les interfaces frontales \u00ab headless \u00bb en tirent un grand b\u00e9n\u00e9fice, car les th\u00e8mes, les plugins et les bundles fournissent de nombreux fichiers. Plus les fichiers restent constants, plus la <strong>Taux de r\u00e9ussite<\/strong> des m\u00e9tadonn\u00e9es. Lorsque j'effectue des d\u00e9ploiements tr\u00e8s fr\u00e9quemment, je raccourcis les intervalles de validation.<\/p>\n\n<p>Le gain est particuli\u00e8rement significatif pour la diffusion de contenu via des SSD locaux. M\u00eame avec des configurations SATA plus anciennes ou des montages NFS, je gagne du temps \u00e0 chaque acc\u00e8s. Je veille \u00e0 n'activer la mise en cache que dans les contextes pertinents (http, serveur ou emplacement). J'\u00e9vite ainsi que des r\u00e9pertoires inappropri\u00e9s ne monopolisent de l'espace de stockage. Une s\u00e9paration claire garantit ici une configuration lisible et un fonctionnement fiable.<\/p>\n\n<h2>Une configuration de d\u00e9marrage qui fonctionne<\/h2>\n\n<p>Je commence par une br\u00e8ve <strong>Base<\/strong>, puis continuez \u00e0 mesurer et \u00e0 ajuster de mani\u00e8re contr\u00f4l\u00e9e. Ces valeurs donnent de bons r\u00e9sultats initiaux sur de nombreux h\u00f4tes et limitent les risques. Important : commencez par v\u00e9rifier avec `nginx -t`, puis ex\u00e9cutez la commande `reload`. Je d\u00e9finis d\u00e9lib\u00e9r\u00e9ment ces directives au niveau http, mais je peux, si n\u00e9cessaire, les utiliser de mani\u00e8re plus cibl\u00e9e dans le bloc location appropri\u00e9. Cela me permet de trouver rapidement un bon \u00e9quilibre entre la consommation de m\u00e9moire et <strong>Performance<\/strong>.<\/p>\n\n<pre><code>open_file_cache max=1000 inactive=20s;\nopen_file_cache_valid 30s;\nopen_file_cache_min_uses 2;\nopen_file_cache_errors off;<\/code><\/pre>\n\n<p>Avec \u00ab max \u00bb, je limite le nombre maximal d'objets mis en cache. \u00ab inactive \u00bb supprime les entr\u00e9es inutilis\u00e9es apr\u00e8s la dur\u00e9e choisie. \u00ab valid \u00bb contr\u00f4le la fr\u00e9quence \u00e0 laquelle NGINX v\u00e9rifie \u00e0 nouveau les m\u00e9tadonn\u00e9es par rapport au syst\u00e8me de fichiers. \u00ab min_uses \u00bb garantit que seuls les fichiers r\u00e9ellement utilis\u00e9s sont stock\u00e9s dans le cache. J'utilise les caches d'erreurs avec mod\u00e9ration afin d'\u00e9viter les faux positifs inutiles.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_cache_optimierung_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionnement correct : max, inactive, min_uses<\/h2>\n\n<p>Je d\u00e9termine la taille du cache en fonction de donn\u00e9es r\u00e9elles <strong>Donn\u00e9es de charge<\/strong> plut\u00f4t que sur des suppositions. Combien de fichiers statiques est-ce que je r\u00e9cup\u00e8re aux heures de pointe, et comment le trafic se r\u00e9partit-il ? \u00c0 mesure que le nombre de fichiers augmente, j'augmente la valeur \u00ab max \u00bb progressivement, g\u00e9n\u00e9ralement par incr\u00e9ments de 500 ou 1 000. Au d\u00e9but, je r\u00e8gle \u00ab inactive \u00bb sur une dur\u00e9e plut\u00f4t courte, jusqu'\u00e0 ce que je puisse \u00e9valuer le comportement avec certitude. \u00ab min_uses \u00bb limite le bruit de fond, afin que les fichiers rarement utilis\u00e9s ne bloquent pas la m\u00e9moire.<\/p>\n\n<p>Pour les sites comportant un tr\u00e8s grand nombre de ressources, je fixe souvent la valeur \u00ab max \u00bb entre 5 000 et 10 000. Pour les petits projets, une valeur comprise entre 500 et 1 500 suffit g\u00e9n\u00e9ralement. Je surveille le taux de r\u00e9ussite, la courbe de RAM des workers NGINX et la latence sur les ressources statiques. Ensuite, je continue \u00e0 ajuster les param\u00e8tres \u00ab max \u00bb et \u00ab inactive \u00bb jusqu\u2019\u00e0 obtenir le bon \u00e9quilibre. En parall\u00e8le, je surveille le c\u00f4t\u00e9 des connexions et je redimensionne si n\u00e9cessaire. <a href=\"https:\/\/webhosting.de\/fr\/nginx-connexions-des-workers-mise-a-lechelle-de-milliers-de-requetes-trafficboost\/\">Faire \u00e9voluer worker_connections<\/a>, afin de ne pas saturer le syst\u00e8me lors des pics de trafic.<\/p>\n\n<h2>Validation et actualit\u00e9 : open_file_cache_valid<\/h2>\n\n<p>Je d\u00e9finis avec <strong>valide<\/strong>, pendant combien de temps NGINX consid\u00e8re les m\u00e9tadonn\u00e9es comme fiables. Dans de nombreux d\u00e9ploiements, j'opte pour une approche plut\u00f4t prudente, par exemple entre 15 et 30 secondes. Lorsque les modifications sont rares, je peux opter pour un intervalle nettement plus long, de l\u2019ordre de 60 \u00e0 300 secondes. Cet intervalle influe sur la fr\u00e9quence \u00e0 laquelle NGINX rev\u00e9rifie les attributs des fichiers, mais pas sur la diffusion du contenu. Cela permet de pr\u00e9server la <strong>Actualit\u00e9<\/strong> \u00e9lev\u00e9, sans que chaque requ\u00eate doive passer par le disque.<\/p>\n\n<p>J'\u00e9vite les valeurs extr\u00eames, car les deux pr\u00e9sentent des inconv\u00e9nients. Des intervalles trop courts augmentent la charge des appels syst\u00e8me. Des intervalles trop longs risquent de faire en sorte que NGINX conserve trop longtemps en m\u00e9moire des m\u00e9tadonn\u00e9es obsol\u00e8tes. Je me base sur la fr\u00e9quence de modification des fichiers et sur les cycles de publication. D\u00e8s que le pipeline de publication est en place, j\u2019ajuste la valeur de `valid` en fonction de ce rythme.<\/p>\n\n<h2>Mise en cache judicieuse des erreurs : open_file_cache_errors<\/h2>\n\n<p>Je peux r\u00e9soudre rapidement des probl\u00e8mes tels que \u201e Fichier introuvable \u201c <strong>mettre en m\u00e9moire tampon<\/strong>, afin d'\u00e9viter les requ\u00eates erron\u00e9es r\u00e9p\u00e9t\u00e9es. Cela vaut la peine en cas de 404 r\u00e9currentes sur des chemins connus mais inexistants. Je r\u00e8gle donc \u00ab errors \u00bb sur \u00ab on \u00bb de mani\u00e8re ponctuelle et maintiens \u00ab inactive \u00bb \u00e0 un niveau mod\u00e9r\u00e9. En revanche, je reste prudent avec les fichiers potentiellement \u00e9ph\u00e9m\u00e8res ayant un cycle de vie court. Cela me permet d\u2019\u00e9viter que des fichiers temporaires <strong>\u00e9tats<\/strong> entra\u00eener des faux n\u00e9gatifs.<\/p>\n\n<p>Pour les cas g\u00e9n\u00e9riques d'erreurs 404, je recommande plut\u00f4t un bloc \u00ab location \u00bb d\u00e9di\u00e9 avec des r\u00e8gles claires. Cela me permet de g\u00e9rer les caches d'erreurs s\u00e9par\u00e9ment du cache de fichiers habituel. Dans des r\u00e9pertoires multim\u00e9dias bien organis\u00e9s, les erreurs sont g\u00e9n\u00e9ralement rares. Cela permet d'\u00e9conomiser de l'espace de stockage et d'\u00e9viter toute confusion lors d'analyses ult\u00e9rieures. Une s\u00e9paration claire facilite ici le d\u00e9pannage.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-cache-optimierung-server-7419.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Synergies : sendfile, tampon, compression<\/h2>\n\n<p>Je combine le cache de fichiers ouverts avec <strong>sendfile<\/strong> en effet, les transferts de fichiers au niveau du noyau \u00e9vitent d'avoir \u00e0 les copier dans l'espace utilisateur. Pour les contenus statiques, cela r\u00e9duit les changements de contexte et assure une diffusion plus fluide. Des tampons de sortie adapt\u00e9s r\u00e9duisent encore davantage les appels syst\u00e8me et maintiennent un d\u00e9bit stable. Gzip ou Brotli compressent les ressources textuelles et r\u00e9duisent ainsi la bande passante et la latence. Parall\u00e8lement, je configure la <a href=\"https:\/\/webhosting.de\/fr\/configurer-de-maniere-optimale-les-processus-de-travail-nginx-pour-ameliorer-les-performances\/\">Processus \u00ab worker \u00bb<\/a> de mani\u00e8re \u00e0 ce qu'ils correspondent \u00e0 la topologie du processeur.<\/p>\n\n<p>J'\u00e9tudie \u00e9galement les strat\u00e9gies d'en-t\u00eates pour la mise en cache c\u00f4t\u00e9 client. Des dur\u00e9es \u00ab Cache-Control \u00bb longues sur des paquets immuables permettent de r\u00e9duire les temps de aller-retour (RTT), tandis que je reste prudent avec les fichiers qui changent fr\u00e9quemment. En combinaison avec les ETags ou la date \u00ab Last-Modified \u00bb, 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 <strong>Temps de r\u00e9ponse<\/strong>.<\/p>\n\n<h2>Linux et le stockage : le r\u00f4le du mat\u00e9riel<\/h2>\n\n<p>Je tire le meilleur parti de <strong>Cache de fichiers<\/strong>, \u00e0 condition que le stockage et la configuration du noyau soient adapt\u00e9s. Des SSD plus rapides, des planificateurs d'E\/S optimis\u00e9s et suffisamment de m\u00e9moire vive pour le cache de pages apportent des gains imm\u00e9diats. En revanche, une utilisation \u00e9lev\u00e9e des inodes et des syst\u00e8mes de fichiers fragment\u00e9s font perdre du temps. Je surveille \u00e9galement le nombre de descripteurs ouverts et j'ajuste les limites du syst\u00e8me. Ainsi, le syst\u00e8me d'exploitation constitue une base efficace pour un fonctionnement rapide <strong>Acc\u00e8s<\/strong>.<\/p>\n\n<p>Sur les h\u00f4tes de machines virtuelles, je tiens compte des effets d\u2019overcommit et de \u00ab voisin bruyant \u00bb. Je v\u00e9rifie si les latences NFS ou r\u00e9seau r\u00e9duisent l\u2019efficacit\u00e9 du cache de fichiers ouverts. Les sc\u00e9narios de conteneurs avec des syst\u00e8mes de fichiers overlay se comportent \u00e9galement diff\u00e9remment selon la structure des couches. Je mesure donc la charge r\u00e9elle en production, et pas seulement des tests sur des r\u00e9pertoires vides. Cela me permet de d\u00e9tecter rapidement les goulots d'\u00e9tranglement et de r\u00e9agir de mani\u00e8re cibl\u00e9e.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_performance_5793.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Suivi et indicateurs : comment mesurer l'impact<\/h2>\n\n<p>Je mesure l'impact \u00e0 travers <strong>Latence<\/strong>, les appels syst\u00e8me, les temps d'attente d'E\/S et les ressources des workers. Des outils tels que strace, perf, iostat et nginx-status m'aident \u00e0 mettre en \u00e9vidence cet effet. Je surveille le \u00ab Time-to-First-Byte \u00bb pour les routes statiques et je compare les situations de \u00ab hit \u00bb et de \u00ab miss \u00bb. Gr\u00e2ce aux journaux, j\u2019identifie les chemins 404 r\u00e9currents ou les r\u00e9pertoires \u00ab chauds \u00bb. En parall\u00e8le, je v\u00e9rifie le <a href=\"https:\/\/webhosting.de\/fr\/file-descriptor-limit-server-hosting-tuning-limites-du-serveur\/\">Limite du descripteur de fichier<\/a>, afin que les handles ouverts ne soient pas bloqu\u00e9s aux limites des processus.<\/p>\n\n<p>Je recueille des indicateurs avant et apr\u00e8s la migration. Ensuite, j'ajuste les param\u00e8tres \u00ab max \u00bb, \u00ab inactive \u00bb et \u00ab valid \u00bb, puis je proc\u00e8de \u00e0 une nouvelle mesure. Deux \u00e0 trois it\u00e9rations suffisent souvent pour atteindre une valeur cible pr\u00e9cise. En cas de pics de trafic, je v\u00e9rifie si les courbes de charge sont plus r\u00e9guli\u00e8res. Ainsi, je ne me contente pas de preuves anecdotiques pour \u00e9tayer les gains, mais je m'appuie sur des donn\u00e9es claires <strong>chiffres<\/strong>.<\/p>\n\n<h2>Les pi\u00e8ges typiques et comment les \u00e9viter<\/h2>\n\n<p>J'active le <strong>Cache<\/strong> Pas de mani\u00e8re globale pour tout, mais uniquement l\u00e0 o\u00f9 cela apporte un avantage. Je soulage les points de terminaison dynamiques autrement, par exemple via les caches d'applications ou des strat\u00e9gies de p\u00e9riph\u00e9rie. Je ne choisis pas au hasard des valeurs max extr\u00eamement \u00e9lev\u00e9es, car la m\u00e9moire vive finit par manquer. Des valeurs \u00ab inactive \u00bb trop longues maintiennent en m\u00e9moire des \u00e9l\u00e9ments obsol\u00e8tes dont aucune requ\u00eate n\u2019a plus besoin. De m\u00eame, des intervalles \u00ab valid \u00bb pr\u00e9matur\u00e9s g\u00e9n\u00e8rent inutilement des appels syst\u00e8me et r\u00e9duisent l\u2019avantage en termes de vitesse.<\/p>\n\n<p>Je d\u00e9finis des directives pour chaque r\u00e9pertoire et je documente les responsabilit\u00e9s. Apr\u00e8s chaque d\u00e9ploiement, je v\u00e9rifie par \u00e9chantillonnage que les fichiers importants sont \u00e0 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\u00f4les r\u00e9guliers. Gr\u00e2ce \u00e0 une maintenance rigoureuse, le cache des fichiers ouverts reste fiable et <strong>efficacement<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_file_cache_performance_6789.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Exemples concrets : petits sites vs grands sites<\/h2>\n\n<p>Je classe les configurations en fonction du nombre de fichiers, du trafic et de la fr\u00e9quence des modifications, et j'en d\u00e9duis <strong>Valeurs<\/strong> . Les petits projets n\u00e9cessitent peu d\u2019entr\u00e9es, des p\u00e9riodes d\u2019inactivit\u00e9 courtes et des p\u00e9riodes de validit\u00e9 mod\u00e9r\u00e9es. Les sites de taille moyenne \u00e0 grande ont recours \u00e0 des valeurs maximales plus \u00e9lev\u00e9es et \u00e0 des intervalles adapt\u00e9s. Les d\u00e9ploiements fr\u00e9quents justifient des p\u00e9riodes de validit\u00e9 plus courtes, tandis que les d\u00e9ploiements rares permettent des p\u00e9riodes plus longues. Le tableau pr\u00e9sente des valeurs de d\u00e9part types, que je v\u00e9rifierai ult\u00e9rieurement par des mesures.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Configuration<\/th>\n      <th>Fichiers (environ)<\/th>\n      <th>max<\/th>\n      <th>inactif<\/th>\n      <th>valide<\/th>\n      <th>min_uses<\/th>\n      <th>Remarque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Petit site<\/td>\n      <td>200\u20131.000<\/td>\n      <td>500\u20131.500<\/td>\n      <td>20-30s<\/td>\n      <td>30 \u00e0 60 s<\/td>\n      <td>2<\/td>\n      <td><strong>\u00c9conomique<\/strong> d\u00e9marrer, v\u00e9rifier<\/td>\n    <\/tr>\n    <tr>\n      <td>Moyens<\/td>\n      <td>1.000\u201310.000<\/td>\n      <td>2.000\u20136.000<\/td>\n      <td>30 \u00e0 60 s<\/td>\n      <td>60 \u00e0 120 s<\/td>\n      <td>2-3<\/td>\n      <td><strong>Trafic<\/strong>- Observer les pics<\/td>\n    <\/tr>\n    <tr>\n      <td>Grand<\/td>\n      <td>10.000+<\/td>\n      <td>6.000\u201310.000<\/td>\n      <td>45 \u00e0 120 s<\/td>\n      <td>120 \u00e0 300 s<\/td>\n      <td>3+<\/td>\n      <td>M\u00e9moire vive et E\/S limit\u00e9es <strong>v\u00e9rifier<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>D\u00e9ploiements fr\u00e9quents<\/td>\n      <td>variable<\/td>\n      <td>adapt\u00e9<\/td>\n      <td>20 \u00e0 45 s<\/td>\n      <td>15 \u00e0 60 s<\/td>\n      <td>2-3<\/td>\n      <td>La fra\u00eecheur avant tout <strong>Taux de r\u00e9ussite<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Liste de contr\u00f4le pour la mise en place<\/h2>\n\n<p>Je pr\u00e9pare un <strong>Plan<\/strong> Tout d'abord, je d\u00e9finis les r\u00e9pertoires dans lesquels la mise en cache des m\u00e9tadonn\u00e9es est utile et j'exclus les zones dynamiques. Ensuite, je d\u00e9finis des valeurs de d\u00e9part prudentes et je v\u00e9rifie la configuration \u00e0 l'aide de la commande `nginx -t`. Je red\u00e9marre NGINX, j'observe les latences et j'examine les journaux ainsi que les m\u00e9triques syst\u00e8me. Je proc\u00e8de ensuite \u00e0 des ajustements progressifs des param\u00e8tres max, inactive, valid et min_uses. Pour finir, je documente les valeurs d\u00e9finitives pour chaque environnement et j'enregistre les modifications avec un num\u00e9ro de version.<\/p>\n\n<p>Je pr\u00e9vois une option de retour en arri\u00e8re au cas o\u00f9 les effets ne seraient pas ceux escompt\u00e9s. Pour les chemins 404 r\u00e9currents, je d\u00e9cide au cas par cas si je mets temporairement les erreurs en cache. Je d\u00e9finis les responsabilit\u00e9s : qui modifie les valeurs, qui effectue les mesures, qui valide les versions. Dans les d\u00e9ploiements comportant de nombreux supports, j'\u00e9tablis des benchmarks par rapport au trafic de pointe. Je proc\u00e8de ainsi de mani\u00e8re m\u00e9thodique et obtiens des r\u00e9sultats durables <strong>R\u00e9sultats<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-cache-optimierung-1045.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Choisir correctement le champ d'application : http, serveur ou emplacement<\/h2>\n\n<p>J'active le cache \u00ab Open File \u00bb l\u00e0 o\u00f9 son efficacit\u00e9 est mesurable. Une activation globale au niveau HTTP est pratique, mais souvent trop g\u00e9n\u00e9rale. Il vaut mieux un <strong>D\u00e9finition du champ d'application<\/strong> par serveur ou par site. Ainsi, les zones dynamiques ne sont pas affect\u00e9es et les r\u00e9pertoires statiques en tirent pleinement parti. Je d\u00e9sactive le cache pour les routes API ou d'administration, je l'active pour les chemins d'acc\u00e8s aux ressources et je le configure sur mesure.<\/p>\n\n<pre><code>http {\n    # Par d\u00e9faut : d\u00e9sactiv\u00e9, afin que les zones dynamiques restent neutres\n    open_file_cache off;\n\n server {\n root \/var\/www\/site;\n\n        # Ressources statiques avec leur propre profil\n location ^~ \/assets\/ {\n open_file_cache max=6000 inactive=60s;\n open_file_cache_valid 120s;\n open_file_cache_min_uses 2;\n            open_file_cache_errors off;\n try_files $uri =404;\n }\n\n # Dynamique : aucun cache de fichiers ouvert n\u00e9cessaire\n location \/api\/ {\n proxy_pass http:\/\/backend;\n }\n    }\n}<\/code><\/pre>\n\n<p>Je commence par quelques lieux bien d\u00e9finis, puis j'\u00e9largis progressivement l'univers. Ainsi, les effets restent compr\u00e9hensibles et j'\u00e9vite les interactions ind\u00e9sirables entre les r\u00e8gles.<\/p>\n\n<h2>Architecture multiprocessus : la RAM et ses limites en ligne de mire<\/h2>\n\n<p>NGINX fonctionne avec plusieurs <strong>Workern<\/strong>, et chaque worker g\u00e8re son propre cache de fichiers ouverts. Cela signifie que le nombre maximal d'entr\u00e9es se multiplie par le nombre de workers. Avec quatre workers et un nombre maximal de 5 000, on peut potentiellement atteindre 20 000 entr\u00e9es dans l'espace des processus. Je pr\u00e9vois donc de la m\u00e9moire vive <em>par travailleur<\/em> et observe les courbes r\u00e9elles. Chaque entr\u00e9e g\u00e9n\u00e8re quelques centaines d'octets de m\u00e9tadonn\u00e9es et de structures de gestion, auxquels s'ajoutent les co\u00fbts li\u00e9s aux descripteurs ouverts.<\/p>\n\n<p>Je pr\u00e9sente \u00e9galement la <strong>Limites des descripteurs de fichiers<\/strong> adapt\u00e9e (\u00e0 l'\u00e9chelle du syst\u00e8me et pour le processus NGINX). Si la limite est insuffisante, les descripteurs ouverts peuvent \u00e9chouer et le cache perd de son efficacit\u00e9. Je v\u00e9rifie la valeur de `ulimit -n` pour l'utilisateur NGINX et, si n\u00e9cessaire, j'utilise `worker_rlimit_nofile` afin d'amortir les pics en toute s\u00e9curit\u00e9. Je v\u00e9rifie le nombre r\u00e9el de fichiers ouverts \u00e0 l'aide de `lsof` ou via les statistiques des processus, afin de ne pas me contenter d'une estimation, mais d'avoir une certitude.<\/p>\n\n<h2>Liens symboliques, alias et try_files : des d\u00e9tails qui font la diff\u00e9rence<\/h2>\n\n<p>Dans la pratique, on rencontre souvent <strong>Liens symboliques<\/strong>, alias et try_files combin\u00e9s. Je veille \u00e0 utiliser correctement alias (avec la s\u00e9mantique des barres obliques appropri\u00e9e) et \u00e0 \u00e9viter les pi\u00e8ges. Les cibles des liens symboliques peuvent changer d\u2019une version \u00e0 l\u2019autre, alors que NGINX conserve encore les m\u00e9tadonn\u00e9es en cache. C\u2019est voulu, tant que l\u2019intervalle \u00ab valid \u00bb est suffisamment court. Pour les chemins sensibles, j\u2019ajoute une s\u00e9curit\u00e9 suppl\u00e9mentaire avec \u00ab disable_symlinks if_not_owner \u00bb.<\/p>\n\n<pre><code>location \/media\/ {\n    # : l'alias doit respecter le format du r\u00e9pertoire (barre oblique finale !)\n    alias \/mnt\/storage\/media\/;\n    disable_symlinks if_not_owner from=\/mnt\/storage;\n    open_file_cache max=8000 inactive=90s;\n    open_file_cache_valid 60s;\n    try_files $uri =404;\n}<\/code><\/pre>\n\n<p>Avec `try_files`, je d\u00e9finis des solutions de repli claires et j'\u00e9vite les cha\u00eenes qui entra\u00eenent des recherches multiples. Des chemins coh\u00e9rents (racine\/alias) et une gestion des erreurs claire permettent de r\u00e9duire les r\u00e9sultats n\u00e9gatifs inutiles dans le cache. Les recherches restent ainsi rapides et transparentes.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-cache-optimierung-1045.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>D\u00e9ploiements sans red\u00e9marrage \u00e0 froid : g\u00e9rer la mise \u00e0 jour<\/h2>\n\n<p>\u00c0 l'adresse suivante : <strong>Temps de descente z\u00e9ro<\/strong>- Lors des d\u00e9ploiements, je remplace souvent un lien symbolique (par exemple, current \u2192 releases\/123). Le cache des fichiers ouverts conserve les anciennes m\u00e9tadonn\u00e9es jusqu'\u00e0 la prochaine validation. Je g\u00e8re cela de mani\u00e8re cibl\u00e9e : soit je d\u00e9finis une valeur plus courte pour `open_file_cache_valid` (par exemple 5 \u00e0 15 s) autour du d\u00e9ploiement, soit je red\u00e9marre NGINX apr\u00e8s la bascule. Un rechargement lance de nouveaux workers qui construisent les nouvelles m\u00e9tadonn\u00e9es, tandis que les anciens workers traitent les requ\u00eates de mani\u00e8re propre. Ainsi, la mise \u00e0 disposition reste stable et la <strong>fra\u00eecheur<\/strong> haut.<\/p>\n\n<p>Lorsque les ensembles d'\u00e9l\u00e9ments sont tr\u00e8s volumineux, je peux ensuite identifier les chemins les plus sollicit\u00e9s <em>se mettre en route<\/em> (par exemple via un bref crawl), afin que les entr\u00e9es les plus importantes soient mises en cache rapidement. Je veille toutefois \u00e0 ce que ce processus reste l\u00e9ger, afin de ne pas g\u00e9n\u00e9rer artificiellement de pics d'E\/S.<\/p>\n\n<h2>Options de syst\u00e8me de fichiers et de montage : de petits r\u00e9glages pour un grand effet<\/h2>\n\n<p>Je fais attention \u00e0 <strong>noatime\/nodiratime<\/strong> lors du montage de volumes locaux. Cela permet d'\u00e9viter des mises \u00e0 jour inutiles de l'atime lors des acc\u00e8s et de r\u00e9duire les E\/S. Sur NFS, la strat\u00e9gie de mise en cache des attributs (par exemple, actimeo) influence la <em>apparente<\/em> Actualit\u00e9 \u2013 je choisis des valeurs compatibles avec \u00ab valid \u00bb afin d\u2019\u00e9viter toute incoh\u00e9rence. Pour les donn\u00e9es de production, je mise sur des syst\u00e8mes de fichiers \u00e9prouv\u00e9s (tels que ext4 ou xfs) et je surveille de pr\u00e8s les r\u00e9serves d'inodes. Les volumes satur\u00e9s ou fortement fragment\u00e9s font perdre du temps, ind\u00e9pendamment de NGINX.<\/p>\n\n<p>Dans des conteneurs dot\u00e9s de syst\u00e8mes de fichiers \u00ab overlay \u00bb, j'\u00e9value l'impact du cache des fichiers ouverts <strong>en charge<\/strong>, et non en mode veille. La superposition peut alourdir les acc\u00e8s aux m\u00e9tadonn\u00e9es ; c\u2019est pourquoi je r\u00e8gle les param\u00e8tres \u00ab inactive \u00bb et \u00ab valid \u00bb de mani\u00e8re plut\u00f4t prudente et me concentre sur les \u00ab hotsets \u00bb.<\/p>\n\n<h2>Compression et variantes statiques : gzip_static, Brotli et Ranges<\/h2>\n\n<p>J'utilise, dans la mesure du possible, <strong>gzip_static<\/strong> (et, de la m\u00eame mani\u00e8re, Brotli), afin de servir directement les fichiers pr\u00e9-compress\u00e9s. Le cache Open File met alors \u00e9galement \u00e0 disposition les m\u00e9tadonn\u00e9es pour les variantes .gz\/.br ; min_uses filtre les formats rares et inhabituels. Les requ\u00eates de plage (range requests) b\u00e9n\u00e9ficient de m\u00e9tadonn\u00e9es stables (taille, mtime), associ\u00e9es \u00e0 sendfile et \u00e0 des r\u00e9glages judicieux de tcp_nopush\/tcp_nodelay.<\/p>\n\n<pre><code>location ~* \\.(?:css|js|svg|json|txt)$ {\n    gzip_static on;  # privil\u00e9gier les fichiers .gz existants\n    sendfile on;\n    tcp_nopush on;\n    open_file_cache max=4000 inactive=45s;\n    open_file_cache_valid 90s;\n    open_file_cache_min_uses 2;\n}<\/code><\/pre>\n\n<p>Je veille \u00e0 la coh\u00e9rence entre l'ETag et la date de derni\u00e8re modification. Cela permet aux clients de proc\u00e9der efficacement \u00e0 la revalidation, et NGINX a ainsi moins souvent besoin d'acc\u00e9der en profondeur au syst\u00e8me de fichiers. Le cache de fichiers ouverts fournit rapidement les m\u00e9tadonn\u00e9es n\u00e9cessaires \u00e0 cet effet.<\/p>\n\n<h2>Analyse approfondie et d\u00e9pannage : ce que je v\u00e9rifie concr\u00e8tement<\/h2>\n\n<ul>\n  <li>Appels syst\u00e8me : \u00e0 titre d'essai, j'applique strace \u00e0 un worker (par exemple, -e trace=open,stat) et je compare la fr\u00e9quence avant et apr\u00e8s l'activation.<\/li>\n  <li>Charge d'E\/S : la commande `iostat -xz`, ex\u00e9cut\u00e9e \u00e0 intervalles r\u00e9guliers, permet de v\u00e9rifier si les temps d'attente et les profondeurs de file d'attente diminuent.<\/li>\n  <li>Chems d'acc\u00e8s erron\u00e9s : les fichiers journaux m'indiquent si des erreurs 404 r\u00e9currentes se produisent. Ces chemins peuvent faire l'objet d'une d\u00e9sactivation temporaire des erreurs \u2013 de mani\u00e8re ponctuelle.<\/li>\n  <li>Limites FD : la commande \u00ab lsof -p  | wc -l \u00bb m'indique un nombre impressionnant de descripteurs ouverts.<\/li>\n  <li>M\u00e9moire : je surveille le flux RSS par worker et je le mets en corr\u00e9lation avec la valeur \u00ab max \u00bb et le taux de r\u00e9ussite des requ\u00eates statiques.<\/li>\n<\/ul>\n\n<p>Lorsque des latences inattendues apparaissent, je v\u00e9rifie d'abord si \u00ab valid \u00bb est trop court (trop de r\u00e9initialisations) ou si \u00ab inactive \u00bb est trop long (fichiers obsol\u00e8tes). Je retire les r\u00e9pertoires corrompus du cache et je refais la mesure. Cela me permet d'isoler rapidement les causes.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_performance_5793.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aspects li\u00e9s \u00e0 la s\u00e9curit\u00e9 et fronti\u00e8res propres<\/h2>\n\n<p>Je s\u00e9pare <strong>clair<\/strong> Je fais la distinction entre les chemins publics et internes, et je d\u00e9sactive l'auto-indexation. Pour les alias et les liens symboliques, j'utilise des variantes restrictives (if_not_owner) afin d'\u00e9viter tout parcours ind\u00e9sirable. Je n'active la mise en cache des erreurs que lorsque je comprends parfaitement le comportement. Dans les environnements multi-locataires, j\u2019isole les caches par vHost afin d\u2019\u00e9viter les chevauchements. Des limites clairement d\u00e9finies facilitent \u00e9galement le d\u00e9bogage, car elles me permettent de mieux identifier les effets par zone.<\/p>\n\n<h2>\u00c9tapes suppl\u00e9mentaires de r\u00e9glage<\/h2>\n\n<p>Je regarde par-dessus le <strong>Cache de fichiers<\/strong> et j'ajuste les param\u00e8tres r\u00e9seau et TLS. Les param\u00e8tres Keepalive, l'utilisation de HTTP\/2 ou HTTP\/3 et des d\u00e9lais d'expiration raisonnables ont une influence significative sur les latences globales. Pour les fichiers volumineux, je v\u00e9rifie sendfile, aio et la taille des tampons de sortie. Je d\u00e9finis des limites raisonnables pour la taille des en-t\u00eates et du corps des requ\u00eates, afin que les requ\u00eates aberrantes ne bloquent pas tout le syst\u00e8me. De plus, je limite la journalisation de mani\u00e8re cibl\u00e9e afin de r\u00e9duire la surcharge \u00e0 <strong>tiennent<\/strong>.<\/p>\n\n<p>C\u00f4t\u00e9 application, je g\u00e8re les caches statiques et dynamiques de mani\u00e8re \u00e0 ce qu'ils n'interf\u00e8rent pas les uns avec les autres. Le versionnage des ressources \u00e0 long terme par hachage r\u00e9duit les revalidations et permet d'allonger la dur\u00e9e de vie des caches c\u00f4t\u00e9 client. Pour les API, je d\u00e9finis des r\u00e8gles courtes et claires et je g\u00e8re les fichiers statiques s\u00e9par\u00e9ment. Je s\u00e9pare les instances NGINX par cas d'utilisation lorsque l'isolation pr\u00e9sente des avantages. Une configuration bien organis\u00e9e permet de gagner du temps lors de l'exploitation et du d\u00e9pannage.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_file_cache_performance_6789.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En bref<\/h2>\n\n<p>Gr\u00e2ce \u00e0 un placement judicieux <strong>Ouvert<\/strong> Gr\u00e2ce au cache de fichiers, je r\u00e9duis les acc\u00e8s au syst\u00e8me de fichiers, j'\u00e9conomise du temps CPU et je fournis les fichiers statiques plus rapidement. Je commence par des valeurs mod\u00e9r\u00e9es, je mesure les effets r\u00e9els, puis j'ajuste progressivement les param\u00e8tres max, inactive, valid et min_uses. Les r\u00e9pertoires statiques en b\u00e9n\u00e9ficient, tandis que j'exclue les points de terminaison dynamiques. En combinaison avec sendfile, l\u2019optimisation des tampons, la compression et des limites syst\u00e8me bien d\u00e9finies, j\u2019am\u00e9liore sensiblement les performances globales. NGINX devient ainsi un serveur fiable <strong>Base<\/strong> pour une livraison rapide et respectueuse des ressources.<\/p>","protected":false},"excerpt":{"rendered":"<p>Configurez correctement le cache de fichiers ouverts NGINX et optimisez les performances de votre serveur gr\u00e2ce aux meilleurs param\u00e8tres.<\/p>","protected":false},"author":1,"featured_media":20891,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20898","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"137","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"NGINX Cache","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20891","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20898","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=20898"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20898\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20891"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20898"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20898"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20898"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}