{"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":"vindue-til-optimering-af-nginx-cachen","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/nginx-cache-optimierung-fenster\/","title":{"rendered":"S\u00e5dan konfigurerer du NGINX Open File Cache optimalt: S\u00e5dan f\u00e5r du mere ydeevne ud af din server"},"content":{"rendered":"<p><strong>NGINX-cache<\/strong> bliver m\u00e6rkbart hurtigere, n\u00e5r jeg indstiller Open File Cache m\u00e5lrettet: Den holder filmetadata og h\u00e5ndtag i hukommelsen og sparer dyre filsystemadgange. Med passende v\u00e6rdier for <strong>max<\/strong>, <strong>inaktiv<\/strong>, <strong>gyldig<\/strong> og <strong>min_brugsgange<\/strong> Jeg optimerer leveringen af statisk indhold med henblik p\u00e5 hurtige svartider og lavere I\/O-belastning.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>Metadatacache<\/strong>: gemmer eksistens, st\u00f8rrelse, tidspunkter og h\u00e5ndtag i stedet for indhold<\/li>\n  <li><strong>Dimensionering<\/strong>: Balance mellem RAM-forbrug, tr\u00e6ffeprocent og \u00e6ndringshastighed<\/li>\n  <li><strong>Kontekster<\/strong>: ideel til billeder\/CSS\/JS; undg\u00e5 dynamiske stier<\/li>\n  <li><strong>Validering<\/strong>: Sikre aktualiteten med open_file_cache_valid<\/li>\n  <li><strong>M\u00e5ling<\/strong>: Kontroller effekter vedr\u00f8rende latenstider, I\/O og fejlprocent<\/li>\n<\/ul>\n\n<h2>Hvad Open File Cache egentlig gemmer<\/h2>\n\n<p>Jeg bruger cache <strong>\u00c5bn fil<\/strong> Cachen indeholder ikke filindhold, men strukturerede oplysninger: Findes en fil, hvor stor er den, hvorn\u00e5r blev den \u00e6ndret, og hvilken deskriptor er allerede \u00e5ben. Disse oplysninger ligger klar i hukommelsen og forkorter vejen til det n\u00e6ste svar. Hver eneste undg\u00e5et harddiskforesp\u00f8rgsel neds\u00e6tter <strong>I\/O-belastning<\/strong> og sparer CPU-tid, hvilket is\u00e6r er vigtigt, n\u00e5r der er tale om mange sm\u00e5 filer. If\u00f8lge NGINX-dokumentationen omfatter funktionen \u00e5bne deskriptorer, mappeoplysninger og s\u00f8gefejl. Dette fremskynder mappescanninger og adgangsstier, som ellers ville skulle hentes fra harddisken p\u00e5 ny ved hver foresp\u00f8rgsel.<\/p>\n\n<p>Jeg bruger bevidst denne mekanisme til mapper, der ofte \u00e5bnes, f.eks. mediebiblioteker og build-assets. Effekten er s\u00e6rlig tydelig i projekter med mange <strong>Aktiver<\/strong>, hvor filsystemet ellers udg\u00f8r en flaskehals. Cachen reducerer systemkald som stat(), open() og readdir() m\u00e6rkbart. Samtidig forbliver kontrollen meget detaljeret, fordi jeg fastl\u00e6gger r\u00e6kkevidden og gyldigheden af posterne separat. P\u00e5 den m\u00e5de holder jeg dataene opdaterede uden at miste fordelen ved cachelagring.<\/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>Hvorn\u00e5r er Open File Cache en god id\u00e9?<\/h2>\n\n<p>Jeg t\u00e6nder for <strong>Cache<\/strong> specielt til statiske leveringer: billeder, CSS, JavaScript, skrifttyper og downloads. I dynamiske omr\u00e5der som login-sider, indk\u00f8bskurve eller personaliserede ruter undg\u00e5r jeg det, da der g\u00e6lder andre regler der. WordPress og headless-frontends drager stor fordel af dette, fordi temaer, plugins og bundter stiller mange filer til r\u00e5dighed. Jo mere konstante filerne er, desto bedre virker <strong>Tr\u00e6fprocent<\/strong> metadataene. Hvis jeg udf\u00f8rer deploymenter meget ofte, indstiller jeg valideringsintervallerne til at v\u00e6re kortere.<\/p>\n\n<p>N\u00e5r det g\u00e6lder levering af indhold via lokale SSD\u2019er, er gevinsten s\u00e6rligt markant. Ogs\u00e5 ved \u00e6ldre SATA-ops\u00e6tninger eller NFS-mounts sparer jeg tid ved hvert eneste hit. Jeg s\u00f8rger for kun at aktivere caching i de relevante sammenh\u00e6nge (http, server eller location). P\u00e5 den m\u00e5de undg\u00e5r jeg, at irrelevante mapper sluger hukommelse. En klar adskillelse sikrer her en overskuelig konfiguration og p\u00e5lidelig drift.<\/p>\n\n<h2>En startkonfiguration, der virker<\/h2>\n\n<p>Jeg begynder med en kortfattet <strong>Basis<\/strong>, m\u00e5le og derefter forts\u00e6tte med at skalere p\u00e5 en kontrolleret m\u00e5de. Disse v\u00e6rdier giver gode indledende resultater p\u00e5 mange servere og holder risikoen lav. Vigtigt: Kontroller f\u00f8rst med `nginx -t` og udf\u00f8r derefter en genindl\u00e6sning. Jeg indstiller bevidst direktiverne p\u00e5 http-niveau, men kan om n\u00f8dvendigt anvende dem mere pr\u00e6cist i den relevante location-blok. P\u00e5 den m\u00e5de finder jeg hurtigt en god balance mellem hukommelsesforbrug og <strong>Ydelse<\/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>Med \u00bbmax\u00ab begr\u00e6nser jeg det maksimale antal cachelagrte objekter. \u00bbinactive\u00ab fjerner ubrugte poster efter den valgte tid. \u00bbvalid\u00ab styrer, hvor ofte NGINX genkontrollerer metadataene i forhold til filsystemet. \u00bbmin_uses\u00ab sikrer, at kun filer, der rent faktisk bruges, ender i cachen. Jeg bruger fejlcacherne med m\u00e5de for at undg\u00e5 un\u00f8dvendige falske hits.<\/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>Korrekt dimensionering: max, inaktiv, min_uses<\/h2>\n\n<p>Jeg bestemmer cachenes st\u00f8rrelse ud fra reelle <strong>Lastdata<\/strong> i stedet for at basere mig p\u00e5 g\u00e6t. Hvor mange statiske filer henter jeg i spidsbelastningsperioder, og hvordan fordeler trafikken sig? N\u00e5r antallet af filer stiger, \u00f8ger jeg max gradvist, typisk i trin p\u00e5 500 eller 1000. I starten holder jeg inactive ret kort, indtil jeg sikkert kan vurdere adf\u00e6rden. min_uses begr\u00e6nser spredningsst\u00f8j, s\u00e5 sj\u00e6ldent anvendte filer ikke blokerer hukommelsen.<\/p>\n\n<p>For websteder med rigtig mange ressourcer ender jeg ofte med en v\u00e6rdi p\u00e5 mellem 5.000 og 10.000. Sm\u00e5 projekter klarer sig ofte fint med 500 til 1.500. Jeg overv\u00e5ger hit-raten, RAM-kurven for NGINX-workere og latenstiden for statiske ressourcer. Derefter justerer jeg v\u00e6rdierne for `max` og `inactive`, indtil balancen er i orden. Samtidig holder jeg \u00f8je med forbindelsessiden og skalerer efter behov. <a href=\"https:\/\/webhosting.de\/da\/nginx-worker-forbindelser-skalering-af-tusindvis-af-anmodninger-trafficboost\/\">Skalering af worker_connections<\/a>, s\u00e5 jeg ikke overbelaster systemet under spidsbelastninger.<\/p>\n\n<h2>Validering og aktualitet: open_file_cache_valid<\/h2>\n\n<p>Jeg definerer med <strong>gyldig<\/strong>, hvor l\u00e6nge NGINX betragter metadata som p\u00e5lidelige. I mange implementeringer v\u00e6lger jeg at v\u00e6re ret konservativ, for eksempel 15 til 30 sekunder. Ved sj\u00e6ldne \u00e6ndringer kan jeg g\u00e5 betydeligt l\u00e6ngere, f.eks. 60 til 300 sekunder. Dette interval p\u00e5virker, hvor ofte NGINX genkontrollerer filattributter, men ikke leveringen af indhold. Dermed forbliver <strong>Aktualitet<\/strong> h\u00f8jt, uden at hver eneste foresp\u00f8rgsel skal sendes til pladen.<\/p>\n\n<p>Jeg undg\u00e5r ekstreme v\u00e6rdier, da begge dele medf\u00f8rer ulemper. For korte intervaller \u00f8ger belastningen p\u00e5 systemkald. For lange intervaller medf\u00f8rer en risiko for, at NGINX opbevarer for\u00e6ldede metadata for l\u00e6nge i hukommelsen. Jeg tager udgangspunkt i filernes \u00e6ndringsfrekvens og i release-cyklusser. S\u00e5 snart release-pipeline er p\u00e5 plads, tilpasser jeg valid til den nye rytme.<\/p>\n\n<h2>Cache fejl p\u00e5 en fornuftig m\u00e5de: open_file_cache_errors<\/h2>\n\n<p>Jeg kan hurtigt l\u00f8se fejl som \u201eFil ikke fundet\u201c <strong>gemme midlertidigt<\/strong>, for at undg\u00e5 gentagne fejlforesp\u00f8rgsler. Det er en god id\u00e9 ved tilbagevendende 404-fejl p\u00e5 kendte, ikke-eksisterende stier. Jeg s\u00e6tter derfor errors til on i udvalgte tilf\u00e6lde og holder inactive p\u00e5 et moderat niveau. Ved potentielt flygtige filer med korte livscyklusser forbliver jeg derimod forsigtig. P\u00e5 den m\u00e5de undg\u00e5r jeg, at midlertidige <strong>tilstande<\/strong> f\u00f8re til falske negative resultater.<\/p>\n\n<p>Til generiske 404-fejl anbefaler jeg snarere et dedikeret location-blok med entydige regler. Der kan jeg administrere fejlcacher adskilt fra den almindelige filcache. I rene mediemapper forekommer der som regel ingen fejl. Det sparer lagerplads og forhindrer misforst\u00e5elser i senere analyser. En klar adskillelse sikrer her bedre fejlfinding.<\/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>Synergier: sendfile, buffer, komprimering<\/h2>\n\n<p>Jeg kombinerer Open File Cache med <strong>sendfile<\/strong> fordi filoverf\u00f8rsler via kernen sparer kopieringsarbejdet i brugerrummet. For statisk indhold betyder det f\u00e6rre kontekstskift og mere j\u00e6vn levering. Passende output-buffere reducerer antallet af systemkald yderligere og holder gennemstr\u00f8mningen stabil. Gzip eller Brotli komprimerer tekstbaserede ressourcer og reducerer b\u00e5ndbredde samt latenstid. Parallelt indstiller jeg <a href=\"https:\/\/webhosting.de\/da\/optimal-konfiguration-af-nginx-arbejdsprocesser-ydeevneforbedring\/\">Arbejderprocesser<\/a> indstilles, s\u00e5 de passer til CPU-topologien.<\/p>\n\n<p>Jeg unders\u00f8ger desuden header-strategier til caching p\u00e5 klientsiden. Lange Cache-Control-tider p\u00e5 uforanderlige bundter sparer RTT\u2019er, mens jeg er forsigtig med filer, der \u00e6ndres ofte. Sammen med ETags eller Last-Modified sikrer jeg effektive revalideringer. P\u00e5 den m\u00e5de samarbejder klientcachen, Open File Cache og komprimering. Det virker som en multiplikator for p\u00e5lidelig <strong>Svartider<\/strong>.<\/p>\n\n<h2>Linux og lagring: hvad hardwaren bidrager med<\/h2>\n\n<p>Jeg f\u00e5r mere ud af <strong>Filcache<\/strong>, hvis lagringsl\u00f8sningen og kernekonfigurationen er i orden. Hurtigere SSD\u2019er, velfungerende I\/O-schedulere og tilstr\u00e6kkelig RAM til sidecachen giver \u00f8jeblikkelige fordele. H\u00f8j inode-udnyttelse og fragmenterede filsystemer koster derimod tid. Jeg holder desuden \u00f8je med antallet af \u00e5bne deskriptorer og justerer systemgr\u00e6nserne. P\u00e5 den m\u00e5de danner operativsystemet et effektivt fundament for hurtig <strong>Adgange<\/strong>.<\/p>\n\n<p>P\u00e5 VM-v\u00e6rter tager jeg h\u00f8jde for overcommit- og noisy-neighbor-effekter. Jeg unders\u00f8ger, om NFS- eller netv\u00e6rksforsinkelser mindsker fordelene ved Open File Cache. Ogs\u00e5 containerscenarier med overlay-filsystemer opf\u00f8rer sig forskelligt afh\u00e6ngigt af lagdelingen. Derfor m\u00e5ler jeg den reelle produktionsbelastning og ikke kun tester p\u00e5 tomme mapper. P\u00e5 den m\u00e5de opdager jeg flaskehalse tidligt og kan reagere m\u00e5lrettet.<\/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>Overv\u00e5gning og n\u00f8gletal: S\u00e5dan m\u00e5ler jeg effekten<\/h2>\n\n<p>Jeg m\u00e5ler effekten ved hj\u00e6lp af <strong>Forsinkelser<\/strong>, systemkald, I\/O-ventetider og worker-ressourcer. V\u00e6rkt\u00f8jer som strace, perf, iostat og nginx-status hj\u00e6lper mig med at synligg\u00f8re effekten. Jeg overv\u00e5ger \u00bbTime-to-First-Byte\u00ab for statiske ruter og sammenligner \u00bbhit\u00ab- og \u00bbmiss\u00ab-situationer. Gennem logfiler identificerer jeg tilbagevendende 404-stier eller \u00bbhot directories\u00ab. Parallelt hermed tjekker jeg <a href=\"https:\/\/webhosting.de\/da\/filbeskrivelsesgraense-serverhosting-tuning-af-servergraenser\/\">Filbeskrivelsesbegr\u00e6nsning<\/a>, s\u00e5 \u00e5bne handler ikke strander p\u00e5 procesgr\u00e6nser.<\/p>\n\n<p>Jeg registrerer m\u00e5lingerne f\u00f8r og efter omstillingen. Derefter justerer jeg max, inactive og valid og m\u00e5ler igen. To til tre iterationer er ofte nok til at n\u00e5 en pr\u00e6cis m\u00e5lv\u00e6rdi. Ved trafikspidser tjekker jeg, om belastningskurverne forl\u00f8ber mere j\u00e6vnt. P\u00e5 den m\u00e5de dokumenterer jeg forbedringerne ikke anekdotisk, men med entydige <strong>Tal<\/strong>.<\/p>\n\n<h2>Typiske faldgruber og hvordan man undg\u00e5r dem<\/h2>\n\n<p>Jeg aktiverer <strong>Cache<\/strong> Ikke globalt for alt, men kun der, hvor det giver en fordel. Dynamiske slutpunkter aflaster jeg p\u00e5 andre m\u00e5der, f.eks. via app-caches eller edge-strategier. Jeg v\u00e6lger ikke ekstremt store max-v\u00e6rdier p\u00e5 m\u00e5 og f\u00e5, for p\u00e5 et tidspunkt vil der mangle RAM. For lange inaktivitetsv\u00e6rdier holder \"d\u00f8de poster\" i hukommelsen, som ingen anmodninger l\u00e6ngere har brug for. Ogs\u00e5 for tidlige valid-intervaller genererer un\u00f8dvendige systemkald og \u00f8del\u00e6gger hastighedsfordelen.<\/p>\n\n<p>Jeg fastl\u00e6gger retningslinjer for hvert katalog og dokumenterer ansvarsfordelingen. Efter implementeringer kontrollerer jeg stikpr\u00f8vevis, om vigtige filer er opdaterede. Jeg formulerer fejlmeddelelser klart, s\u00e5 404-analyser ikke g\u00e5r tabt i st\u00f8j. Advarsler i fejlloggen er en del af min regelm\u00e6ssige kontrol. Med disciplineret vedligeholdelse forbliver Open File Cache p\u00e5lidelig og <strong>effektiv<\/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>Praktiske eksempler: sm\u00e5 vs. store websteder<\/h2>\n\n<p>Jeg inddeler ops\u00e6tningerne efter antal filer, trafik og hyppighed af \u00e6ndringer og ud fra det <strong>V\u00e6rdier<\/strong> . Mindre projekter kr\u00e6ver f\u00e5 poster, korte inactives og moderate valids. Mellemstore til store websteder anvender h\u00f8jere max-v\u00e6rdier og tilpassede intervaller. Hyppige deployments berettiger kortere valids, mens sj\u00e6ldne deployments tillader l\u00e6ngere. Tabellen viser typiske udgangspunkter, som jeg senere justerer p\u00e5 baggrund af m\u00e5linger.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Ops\u00e6tning<\/th>\n      <th>Filer (ca.)<\/th>\n      <th>max<\/th>\n      <th>inaktiv<\/th>\n      <th>gyldig<\/th>\n      <th>min_brugsgange<\/th>\n      <th>Hint<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Lille hjemmeside<\/td>\n      <td>200\u20131.000<\/td>\n      <td>500\u20131.500<\/td>\n      <td>20-30s<\/td>\n      <td>30\u201360 sekunder<\/td>\n      <td>2<\/td>\n      <td><strong>\u00d8konomisk<\/strong> starte, efterm\u00e5le<\/td>\n    <\/tr>\n    <tr>\n      <td>Medium<\/td>\n      <td>1.000\u201310.000<\/td>\n      <td>2.000\u20136.000<\/td>\n      <td>30\u201360 sekunder<\/td>\n      <td>60\u2013120 sekunder<\/td>\n      <td>2-3<\/td>\n      <td><strong>Trafik<\/strong>-Overv\u00e5ge toppe<\/td>\n    <\/tr>\n    <tr>\n      <td>Stor<\/td>\n      <td>10.000+<\/td>\n      <td>6.000\u201310.000<\/td>\n      <td>45\u2013120 sekunder<\/td>\n      <td>120\u2013300 s<\/td>\n      <td>3+<\/td>\n      <td>RAM og I\/O er t\u00e6t p\u00e5 hinanden <strong>Tjek<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Hyppige implementeringer<\/td>\n      <td>variabel<\/td>\n      <td>tilpasset<\/td>\n      <td>20\u201345 sekunder<\/td>\n      <td>15\u201360 sekunder<\/td>\n      <td>2-3<\/td>\n      <td>Friskhed f\u00f8rst <strong>Tr\u00e6fprocent<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Tjekliste til implementering<\/h2>\n\n<p>Jeg laver en klar <strong>Planl\u00e6g<\/strong> F\u00f8rst: Jeg definerer de mapper, hvor caching af metadata giver fordele, og afgr\u00e6nser de dynamiske zoner. Derefter indstiller jeg konservative startv\u00e6rdier og tester konfigurationen med `nginx -t`. Jeg genstarter NGINX, overv\u00e5ger latenstiderne og gennemg\u00e5r logfiler samt systemmetrikker. Derefter justerer jeg max, inactive, valid og min_uses i sm\u00e5 trin. Til sidst dokumenterer jeg de endelige v\u00e6rdier for hvert milj\u00f8 og gemmer \u00e6ndringerne med versionsnummer.<\/p>\n\n<p>Jeg har en rollback-mulighed klar, hvis resultaterne bliver anderledes end forventet. For tilbagevendende 404-stier beslutter jeg fra sag til sag, om jeg kortvarigt skal cache fejl. Jeg beskriver ansvarsfordelingen: Hvem \u00e6ndrer v\u00e6rdier, hvem m\u00e5ler, hvem godkender udgivelser. Ved implementeringer med mange medier opstiller jeg benchmarks i forhold til spidsbelastning. P\u00e5 den m\u00e5de arbejder jeg planm\u00e6ssigt og opn\u00e5r b\u00e6redygtige <strong>Resultater<\/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>V\u00e6lg anvendelsesomr\u00e5de korrekt: http, server eller location<\/h2>\n\n<p>Jeg aktiverer Open File Cache der, hvor det har en m\u00e5lbar effekt. At g\u00f8re det globalt p\u00e5 http-niveau er praktisk, men ofte for groft. Bedre er en <strong>Afgr\u00e6nsning<\/strong> pr. server eller lokation. P\u00e5 den m\u00e5de forbliver dynamiske omr\u00e5der uber\u00f8rte, mens statiske mapper drager maksimal fordel. For API- eller admin-ruter lader jeg cachen v\u00e6re sl\u00e5et fra, mens jeg for asset-stier sl\u00e5r den til og tilpasser den efter behov.<\/p>\n\n<pre><code>http {\n    # Standard: sl\u00e5et fra, s\u00e5 dynamiske zoner forbliver neutrale\n    open_file_cache off;\n\n server {\n root \/var\/www\/site;\n\n        # Statiske ressourcer med egen 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 # Dynamik: ingen Open File Cache n\u00f8dvendig\n location \/api\/ {\n proxy_pass http:\/\/backend;\n }\n    }\n}<\/code><\/pre>\n\n<p>Jeg starter med f\u00e5, klare lokationer og udvider gradvist. P\u00e5 den m\u00e5de forbliver effekterne overskuelige, og jeg undg\u00e5r u\u00f8nskede interaktioner mellem reglerne.<\/p>\n\n<h2>Multiprocesarkitektur: RAM og begr\u00e6nsninger i fokus<\/h2>\n\n<p>NGINX arbejder med flere <strong>Arbejdere<\/strong>, og hver worker administrerer sin egen Open File Cache. Det betyder, at antallet af max-poster ganges med antallet af workere. Fire workere og max=5000 giver potentielt op til 20.000 poster p\u00e5 tv\u00e6rs af procesrummet. Jeg planl\u00e6gger derfor RAM <em>pr. medarbejder<\/em> og f\u00f8lg de faktiske kurver. Hver post medf\u00f8rer et par hundrede byte i metadata og administrationsstrukturer, plus omkostninger til \u00e5bne deskriptorer.<\/p>\n\n<p>Jeg pr\u00e6senterer desuden <strong>Begr\u00e6nsninger for filbeskrivere<\/strong> indstilles passende (p\u00e5 systemniveau og for NGINX-processen). Hvis gr\u00e6nsen ikke er tilstr\u00e6kkelig, kan \u00e5bne h\u00e5ndtag mislykkes, og cachen mister sin effekt. Jeg tjekker ulimit -n for NGINX-brugeren og bruger om n\u00f8dvendigt worker_rlimit_nofile, s\u00e5 spidsbelastninger kan h\u00e5ndteres sikkert. Det faktiske antal \u00e5bne filer kontrollerer jeg med lsof eller via processtatistikker, s\u00e5 jeg ikke blot g\u00e6tter, men ved det med sikkerhed.<\/p>\n\n<h2>Symlinks, alias og try_files: Detaljer med stor betydning<\/h2>\n\n<p>I praksis forekommer det ofte, at <strong>Symlinks<\/strong>, alias og try_files sammen. Jeg s\u00f8rger for at bruge alias korrekt (med den rette skr\u00e5streg-semantik) og undg\u00e5 faldgruber. Symlink-m\u00e5l kan \u00e6ndre sig ved nye udgivelser, mens NGINX stadig opbevarer metadata i cachen. Dette er tilsigtet, s\u00e5 l\u00e6nge valid-intervallet er kort nok. Ved f\u00f8lsomme stier sikrer jeg mig yderligere med `disable_symlinks if_not_owner`.<\/p>\n\n<pre><code>location \/media\/ {\n    # alias skal passe til mappestilen (afsluttende skr\u00e5streg!)\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>N\u00e5r jeg bruger `try_files`, angiver jeg klare fallbacks og undg\u00e5r k\u00e6der, der medf\u00f8rer flere opslag. Konsistente stier (root\/alias) og entydig fejlh\u00e5ndtering reducerer un\u00f8dvendige negative hits i cachen. P\u00e5 den m\u00e5de forbliver opslagene hurtige og gennemsigtige.<\/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>Implementeringer uden koldstart: Styring af aktualiteten<\/h2>\n\n<p>Med <strong>Ingen nedetid<\/strong>-Ved udrulninger skifter jeg ofte et symbolsk link (f.eks. current \u2192 releases\/123). Open File Cache gemmer gamle metadata indtil den n\u00e6ste validering. Det styrer jeg bevidst: Enten indstiller jeg en kortere `open_file_cache_valid` (f.eks. 5\u201315 sekunder) omkring implementeringen, eller ogs\u00e5 genstarter jeg NGINX efter skiftet. En genindl\u00e6sning starter nye workere, der opbygger nye metadata, mens gamle workere forts\u00e6tter med at behandle anmodninger uden problemer. P\u00e5 den m\u00e5de forbliver leveringen stabil, og <strong>Friskhed<\/strong> h\u00f8j.<\/p>\n\n<p>Ved meget store s\u00e6t af aktiver kan jeg efterf\u00f8lgende identificere \u00bbhot paths\u00ab <em>opvarmning<\/em> (f.eks. via en kort crawl), s\u00e5 de vigtigste poster hurtigt havner i cachen. Jeg holder det dog p\u00e5 et minimum for ikke at skabe kunstige I\/O-spidsbelastninger.<\/p>\n\n<h2>Filsystem- og monteringsindstillinger: sm\u00e5 justeringer, stor effekt<\/h2>\n\n<p>Jeg er opm\u00e6rksom p\u00e5 <strong>noatime\/nodiratime<\/strong> ved montering af lokale diskenheder. Dermed undg\u00e5r man un\u00f8dvendige aTime-opdateringer ved adgang og reducerer I\/O. P\u00e5 NFS p\u00e5virker attribut-cache-strategien (f.eks. actimeo) den <em>tilsyneladende<\/em> Aktualitet \u2013 jeg v\u00e6lger v\u00e6rdier, der passer til valid, for at undg\u00e5 inkonsekvenser. Til produktionsdata satser jeg p\u00e5 velafpr\u00f8vede filsystemer (f.eks. ext4 eller xfs) og holder \u00f8je med inode-reserverne. Overfyldte eller st\u00e6rkt fragmenterede diskenheder koster tid, helt uafh\u00e6ngigt af NGINX.<\/p>\n\n<p>I containere med overlay-filsystemer vurderer jeg effekten af Open File Cache <strong>under belastning<\/strong>, ikke i tomgang. Lagdeling kan g\u00f8re adgangen til metadata dyrere; derfor indstiller jeg \u00bbinactive\u00ab og \u00bbvalid\u00ab ret konservativt og fokuserer p\u00e5 hotsets.<\/p>\n\n<h2>Komprimering og statiske varianter: gzip_static, Brotli og Ranges<\/h2>\n\n<p>Jeg bruger, hvor det er muligt, <strong>gzip_static<\/strong> (og tilsvarende Brotli) for at kunne levere forh\u00e5ndskomprimerede filer direkte. Open File Cache indeholder derefter ogs\u00e5 metadataene for .gz\/.br-varianter; min_uses filtrerer sj\u00e6ldne, us\u00e6dvanlige filtyper fra. Range-anmodninger drager fordel af stabile metadata (st\u00f8rrelse, mtime) sammen med sendfile og en fornuftig indstilling af tcp_nopush\/tcp_nodelay.<\/p>\n\n<pre><code>location ~* \\.(?:css|js|svg|json|txt)$ {\n    gzip_static on;  # foretr\u00e6kker eksisterende .gz-filer\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>Jeg s\u00f8rger for, at ETag og Last-Modified er konsistente. P\u00e5 den m\u00e5de kan klienter revalidere effektivt, og NGINX beh\u00f8ver sj\u00e6ldnere at g\u00e5 dybt ned i filsystemet. Open File Cache leverer hurtigt de n\u00f8dvendige metadata til dette form\u00e5l.<\/p>\n\n<h2>Dybdeg\u00e5ende indsigt og fejlfinding: hvad jeg konkret tjekker<\/h2>\n\n<ul>\n  <li>Systemkald: Jeg k\u00f8rer strace p\u00e5 en worker som test (f.eks. -e trace=open,stat) og sammenligner hyppigheden f\u00f8r og efter aktivering.<\/li>\n  <li>I\/O-belastning: Kommandoen `iostat -xz`, k\u00f8rt med korte intervaller, viser, om ventetiderne og k\u00f8dybderne falder.<\/li>\n  <li>Fejlstier: Logfilerne fort\u00e6ller mig, om der opst\u00e5r tilbagevendende 404-fejl. Disse stier opfylder betingelserne for kortvarig aktivering af \u00bberrors on\u00ab \u2013 punktuelt.<\/li>\n  <li>FD-gr\u00e6nser: lsof -p  | wc -l viser mig et enormt antal \u00e5bne deskriptorer.<\/li>\n  <li>Cache: Jeg overv\u00e5ger RSS pr. worker og sammenholder det med max og hit-raten for statiske anmodninger.<\/li>\n<\/ul>\n\n<p>Hvis der opst\u00e5r uventede forsinkelser, tjekker jeg f\u00f8rst, om \u00bbvalid\u00ab er for kort (for mange genstarter) eller \u00bbinactive\u00ab er for lang (gamle poster). Enkelte problematiske mapper fjerner jeg fra cachen og m\u00e5ler igen. P\u00e5 den m\u00e5de kan jeg hurtigt finde \u00e5rsagerne.<\/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>Sikkerhedsaspekter og rene gr\u00e6nser<\/h2>\n\n<p>Jeg skiller mig ud <strong>klar<\/strong> mellem offentlige og interne stier og undg\u00e5r autoindex. Ved aliaser og symlinks anvender jeg restriktive varianter (if_not_owner), s\u00e5 der ikke opst\u00e5r u\u00f8nskede traverseringer. Jeg aktiverer kun fejlcaching der, hvor jeg forst\u00e5r adf\u00e6rden. I multi-tenant-milj\u00f8er isolerer jeg cacher pr. vHost for at undg\u00e5 overlapninger. Tydelige gr\u00e6nser hj\u00e6lper ogs\u00e5 med fejlfinding, fordi jeg bedre kan tilordne effekter pr. zone.<\/p>\n\n<h2>Yderligere trin i optimeringen<\/h2>\n\n<p>Jeg kigger ud over <strong>Filcache<\/strong> og justerer netv\u00e6rks- og TLS-parametre. Keepalive-indstillinger, brug af HTTP\/2 eller HTTP\/3 samt fornuftige timeouts har en betydelig indflydelse p\u00e5 den samlede latenstid. Ved store filer tjekker jeg sendfile, aio og st\u00f8rrelsen p\u00e5 output-bufferne. Jeg indstiller fornuftige gr\u00e6nser for header- og body-st\u00f8rrelser, s\u00e5 us\u00e6dvanligt store anmodninger ikke blokerer det hele. Desuden holder jeg logningen m\u00e5lrettet for at minimere overheadet <strong>Hold fast<\/strong>.<\/p>\n\n<p>P\u00e5 app-siden rydder jeg op i statiske og dynamiske cacher, s\u00e5 de ikke kommer i vejen for hinanden. Versionsstyring af langtidsaktiver via hash mindsker antallet af revalideringer og muligg\u00f8r l\u00e6ngere klientcacher. For API\u2019er fasts\u00e6tter jeg korte, klare regler og k\u00f8rer statiske filer separat. Jeg adskiller NGINX-instanser efter anvendelsestilf\u00e6lde, n\u00e5r isolation giver fordele. En velordnet konfiguration sparer tid i driften og ved fejlfinding.<\/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>Kort opsummeret<\/h2>\n\n<p>Med en m\u00e5lrettet <strong>\u00c5ben<\/strong> Med filcachen reducerer jeg antallet af filsystemadgange, sparer CPU-tid og leverer statiske filer hurtigere. Jeg starter med moderate v\u00e6rdier, m\u00e5ler de faktiske effekter og justerer derefter gradvist indstillingerne for max, inactive, valid og min_uses. Statiske mapper drager fordel heraf, mens jeg udelader dynamiske slutpunkter. Sammen med sendfile, buffer-tuning, komprimering og solide systemgr\u00e6nser forbedrer jeg den samlede ydeevne m\u00e6rkbart. P\u00e5 den m\u00e5de bliver NGINX en p\u00e5lidelig <strong>Basis<\/strong> for hurtig og ressourcebesparende levering.<\/p>","protected":false},"excerpt":{"rendered":"<p>Konfigurer NGINX Open File Cache korrekt, og opn\u00e5 bedre ydeevne p\u00e5 din server med de bedste parametre.<\/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":"144","_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\/da\/wp-json\/wp\/v2\/posts\/20898","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=20898"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20898\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20891"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20898"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20898"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20898"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}