{"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":"foenster-foer-optimering-av-nginx-cachen","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/nginx-cache-optimierung-fenster\/","title":{"rendered":"Optimera inst\u00e4llningarna f\u00f6r NGINX Open File Cache: S\u00e5 h\u00e4r f\u00e5r du ut b\u00e4ttre prestanda ur din server"},"content":{"rendered":"<p><strong>NGINX-cache<\/strong> blir m\u00e4rkbart snabbare n\u00e4r jag st\u00e4ller in Open File Cache p\u00e5 r\u00e4tt s\u00e4tt: Den lagrar filmetadata och handtag i minnet och sparar in kostsamma filsystem\u00e5tkomster. Med l\u00e4mpliga v\u00e4rden f\u00f6r <strong>max<\/strong>, <strong>inaktiv<\/strong>, <strong>giltig<\/strong> och <strong>min_anv\u00e4ndningar<\/strong> jag optimerar leveransen av statiskt inneh\u00e5ll f\u00f6r snabba svarstider och l\u00e4gre I\/O-belastning.<\/p>\n\n<h2>Centrala punkter<\/h2>\n\n<ul>\n  <li><strong>Metadatacache<\/strong>: lagrar f\u00f6rekomst, storlek, tidpunkter och handtag ist\u00e4llet f\u00f6r inneh\u00e5ll<\/li>\n  <li><strong>Dimensionering<\/strong>: Balans mellan RAM-anv\u00e4ndning, tr\u00e4ffs\u00e4kerhet och f\u00f6r\u00e4ndringstakt<\/li>\n  <li><strong>Sammanhang<\/strong>: perfekt f\u00f6r bilder\/CSS\/JS; undvik dynamiska s\u00f6kv\u00e4gar<\/li>\n  <li><strong>Validering<\/strong>: S\u00e4kerst\u00e4lla aktualiteten med open_file_cache_valid<\/li>\n  <li><strong>M\u00e4tning<\/strong>: Kontrollera effekterna av f\u00f6rdr\u00f6jningar, I\/O och felfrekvens<\/li>\n<\/ul>\n\n<h2>Vad Open File Cache egentligen lagrar<\/h2>\n\n<p>Jag anv\u00e4nder cache <strong>\u00d6ppna fil<\/strong> Cachen lagrar inte filinneh\u00e5ll, utan strukturerade uppgifter: Finns filen, hur stor \u00e4r den, n\u00e4r \u00e4ndrades den och vilken deskriptor \u00e4r redan \u00f6ppen. Denna information finns tillg\u00e4nglig i minnet och f\u00f6rkortar v\u00e4gen till n\u00e4sta svar. Varje h\u00e5rddisk\u00e5tkomst som undviks minskar <strong>I\/O-belastning<\/strong> och sparar CPU-tid, vilket \u00e4r s\u00e4rskilt viktigt n\u00e4r det g\u00e4ller m\u00e5nga sm\u00e5 filer. Enligt NGINX-dokumentationen omfattar funktionen \u00f6ppna deskriptorer, kataloginformation och s\u00f6kfel. Detta p\u00e5skyndar kataloggenomg\u00e5ngar och \u00e5tkomstv\u00e4gar, som annars skulle beh\u00f6va h\u00e4mtas fr\u00e5n h\u00e5rddisken p\u00e5 nytt vid varje f\u00f6rfr\u00e5gan.<\/p>\n\n<p>Jag anv\u00e4nder medvetet denna mekanism f\u00f6r kataloger som anv\u00e4nds ofta, till exempel mediebibliotek och byggresurser. Effekten m\u00e4rks tydligt i projekt med m\u00e5nga <strong>Tillg\u00e5ngar<\/strong>, d\u00e4r filsystemet annars skulle bli en flaskhals. Cachen minskar m\u00e4rkbart antalet systemanrop som stat(), open() och readdir(). Samtidigt f\u00f6rblir kontrollen mycket detaljerad, eftersom jag separat fastst\u00e4ller r\u00e4ckvidden och giltighetstiden f\u00f6r posterna. P\u00e5 s\u00e5 s\u00e4tt h\u00e5ller jag data uppdaterade utan att f\u00f6rlora f\u00f6rdelen med 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>N\u00e4r det l\u00f6nar sig att anv\u00e4nda Open File Cache<\/h2>\n\n<p>Jag sl\u00e5r p\u00e5 <strong>Cache<\/strong> specifikt f\u00f6r statiska leveranser: bilder, CSS, JavaScript, teckensnitt och nedladdningar. I dynamiska zoner som inloggningssidor, varukorgar eller personaliserade fl\u00f6den undviker jag den, d\u00e4r g\u00e4ller andra regler. WordPress och headless-frontends drar stor nytta av detta, eftersom teman, plugins och paket tillhandah\u00e5ller m\u00e5nga filer. Ju mer konstanta filerna \u00e4r, desto b\u00e4ttre fungerar <strong>Tr\u00e4fffrekvens<\/strong> metadata. Om jag utf\u00f6r distributioner mycket ofta justerar jag valideringsintervallen s\u00e5 att de blir kortare.<\/p>\n\n<p>N\u00e4r det g\u00e4ller inneh\u00e5llsleverans via lokala SSD-enheter \u00e4r vinsten s\u00e4rskilt tydlig. \u00c4ven med \u00e4ldre SATA-konfigurationer eller NFS-monteringar sparar jag tid f\u00f6r varje tr\u00e4ff. Jag ser till att endast aktivera cachelagring i relevanta sammanhang (http, server eller plats). P\u00e5 s\u00e5 s\u00e4tt undviker jag att ol\u00e4mpliga kataloger tar upp on\u00f6digt med lagringsutrymme. En tydlig uppdelning s\u00e4kerst\u00e4ller h\u00e4r en \u00f6versk\u00e5dlig konfiguration och p\u00e5litlig funktion.<\/p>\n\n<h2>En startkonfiguration som fungerar<\/h2>\n\n<p>Jag b\u00f6rjar med en kortfattad <strong>Bas<\/strong>, m\u00e4t och skala sedan vidare p\u00e5 ett kontrollerat s\u00e4tt. Dessa v\u00e4rden ger bra utg\u00e5ngsresultat p\u00e5 m\u00e5nga servrar och minimerar risken. Viktigt: Kontrollera f\u00f6rst med nginx -t och utf\u00f6r sedan en omladdning. Jag placerar direktiven medvetet p\u00e5 http-niv\u00e5, men kan vid behov anv\u00e4nda dem mer specifikt i l\u00e4mpligt location-block. P\u00e5 s\u00e5 s\u00e4tt hittar jag snabbt en bra balans mellan minnesanv\u00e4ndning och <strong>Prestanda<\/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 `max` begr\u00e4nsar jag det maximala antalet cachelagrade objekt. `inactive` tar bort oanv\u00e4nda poster efter den valda tiden. `valid` styr hur ofta NGINX kontrollerar metadata mot filsystemet p\u00e5 nytt. `min_uses` ser till att endast filer som verkligen anv\u00e4nds hamnar i cachen. Jag anv\u00e4nder felcacherna med m\u00e5tta f\u00f6r att undvika on\u00f6diga negativa tr\u00e4ffar.<\/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>Jag best\u00e4mmer cacheminnets storlek utifr\u00e5n verkliga <strong>Lastdata<\/strong> ist\u00e4llet f\u00f6r gissningar. Hur m\u00e5nga statiska filer h\u00e4mtar jag under toppbelastningar, och hur f\u00f6rdelar sig trafiken? N\u00e4r antalet filer \u00f6kar h\u00f6jer jag max stegvis, vanligtvis i steg om 500 eller 1 000. I b\u00f6rjan h\u00e5ller jag inactive ganska kort, tills jag s\u00e4kert kan bed\u00f6ma beteendet. min_uses begr\u00e4nsar spridningsbruset s\u00e5 att s\u00e4llan anv\u00e4nda filer inte blockerar minnet.<\/p>\n\n<p>F\u00f6r webbplatser med v\u00e4ldigt m\u00e5nga resurser hamnar jag ofta p\u00e5 ett maxv\u00e4rde mellan 5 000 och 10 000. F\u00f6r mindre projekt r\u00e4cker det ofta med 500 till 1 500. Jag \u00f6vervakar tr\u00e4fffrekvensen, RAM-kurvan f\u00f6r NGINX-arbetare och latensen f\u00f6r statiska resurser. D\u00e4refter justerar jag v\u00e4rdena f\u00f6r max och inactive tills f\u00f6rh\u00e5llandet st\u00e4mmer. Parallellt tittar jag p\u00e5 anslutningssidan och skalar vid behov. <a href=\"https:\/\/webhosting.de\/sv\/nginx-arbetaranslutningar-skalning-av-tusentals-foerfragningar-trafficboost\/\">Skala worker_connections<\/a>, s\u00e5 att jag inte \u00f6verbelastar systemet under trafiktoppar.<\/p>\n\n<h2>Validering och aktualitet: open_file_cache_valid<\/h2>\n\n<p>Jag definierar med <strong>giltig<\/strong>, hur l\u00e4nge NGINX betraktar metadata som tillf\u00f6rlitliga. Vid m\u00e5nga drifts\u00e4ttningar v\u00e4ljer jag en ganska konservativ inst\u00e4llning, till exempel 15 till 30 sekunder. Vid s\u00e4llsynta \u00e4ndringar kan jag v\u00e4lja ett betydligt l\u00e4ngre intervall, till exempel 60 till 300 sekunder. Detta intervall p\u00e5verkar hur ofta NGINX kontrollerar filattributen p\u00e5 nytt, men inte leveransen av inneh\u00e5ll. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir <strong>Aktualitet<\/strong> h\u00f6gt, utan att varje f\u00f6rfr\u00e5gan m\u00e5ste g\u00e5 via skivan.<\/p>\n\n<p>Jag undviker extrema v\u00e4rden, eftersom b\u00e5da medf\u00f6r nackdelar. F\u00f6r korta intervall \u00f6kar belastningen p\u00e5 systemanropen. F\u00f6r l\u00e5nga intervall inneb\u00e4r en risk att NGINX beh\u00e5ller f\u00f6r\u00e5ldrade metadata i minnet f\u00f6r l\u00e4nge. Jag utg\u00e5r fr\u00e5n filernas \u00e4ndringsfrekvens och release-cyklerna. S\u00e5 snart release-pipeline \u00e4r p\u00e5 plats anpassar jag valid efter rytmen.<\/p>\n\n<h2>Cachea fel p\u00e5 ett meningsfullt s\u00e4tt: open_file_cache_errors<\/h2>\n\n<p>Jag kan snabbt \u00e5tg\u00e4rda fel som \u201eFilen hittades inte\u201c <strong>lagra tillf\u00e4lligt<\/strong>, f\u00f6r att minska belastningen fr\u00e5n upprepade felaktiga f\u00f6rfr\u00e5gningar. Det l\u00f6nar sig vid \u00e5terkommande 404-fel p\u00e5 k\u00e4nda, icke-existerande s\u00f6kv\u00e4gar. Jag st\u00e4ller d\u00e4rf\u00f6r in errors p\u00e5 on i vissa fall och h\u00e5ller inactive p\u00e5 en m\u00e5ttlig niv\u00e5. N\u00e4r det g\u00e4ller potentiellt flyktiga filer med korta livscykler \u00e4r jag d\u00e4remot f\u00f6rsiktig. P\u00e5 s\u00e5 s\u00e4tt undviker jag att tillf\u00e4lliga <strong>tillst\u00e5nd<\/strong> leda till falska negativa tr\u00e4ffar.<\/p>\n\n<p>F\u00f6r generiska 404-fall rekommenderar jag hellre ett s\u00e4rskilt \u201dlocation\u201d-block med tydliga regler. D\u00e4r kan jag hantera felcachen separat fr\u00e5n den vanliga filcachen. I v\u00e4lordnade mediekataloger uppst\u00e5r vanligtvis inga fel. Det sparar lagringsutrymme och f\u00f6rhindrar missf\u00f6rst\u00e5nd vid senare analyser. En tydlig \u00e5tskillnad underl\u00e4ttar fels\u00f6kningen.<\/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, buffert, komprimering<\/h2>\n\n<p>Jag kombinerar Open File Cache med <strong>sendfile<\/strong> eftersom fil\u00f6verf\u00f6ringar via k\u00e4rnan sparar in kopieringsarbetet i anv\u00e4ndarutrymmet. F\u00f6r statiskt inneh\u00e5ll inneb\u00e4r detta f\u00e4rre kontextbyten och smidigare leveranser. L\u00e4mpliga utdatabuffertar minskar systemanropen ytterligare och h\u00e5ller genomstr\u00f6mningen stabil. Gzip eller Brotli komprimerar textbaserade tillg\u00e5ngar och minskar b\u00e5de bandbredd och latens. Parallellt st\u00e4ller jag in <a href=\"https:\/\/webhosting.de\/sv\/konfigurera-nginx-arbetsprocesser-optimalt-foer-baettre-prestanda\/\">Arbetarprocesser<\/a> s\u00e5 att de passar in i CPU-topologin.<\/p>\n\n<p>Jag unders\u00f6ker dessutom header-strategier f\u00f6r cachelagring p\u00e5 klientsidan. L\u00e5nga Cache-Control-tider f\u00f6r of\u00f6r\u00e4nderliga paket sparar RTT, medan jag \u00e4r f\u00f6rsiktig n\u00e4r det g\u00e4ller filer som \u00e4ndras ofta. Tillsammans med ETags eller Last-Modified s\u00e4kerst\u00e4ller jag effektiva omvalideringar. P\u00e5 s\u00e5 s\u00e4tt samverkar klientcachen, Open File Cache och komprimeringen. Detta fungerar som en multiplikator f\u00f6r tillf\u00f6rlitlig <strong>Svarstider<\/strong>.<\/p>\n\n<h2>Linux och lagring: vad h\u00e5rdvaran bidrar med<\/h2>\n\n<p>Jag f\u00e5r ut mer av <strong>Filcache<\/strong>, om lagringsutrymmet och k\u00e4rnkonfigurationen st\u00e4mmer. Snabbare SSD-enheter, v\u00e4lfungerande I\/O-schemal\u00e4ggare och tillr\u00e4ckligt med RAM f\u00f6r sidcachen ger omedelbara f\u00f6rdelar. H\u00f6g inod-belastning och fragmenterade filsystem kostar d\u00e4remot tid. Jag h\u00e5ller dessutom koll p\u00e5 antalet \u00f6ppna deskriptorer och justerar systemgr\u00e4nserna. P\u00e5 s\u00e5 s\u00e4tt utg\u00f6r operativsystemet en effektiv grund f\u00f6r snabb <strong>Tilltr\u00e4den<\/strong>.<\/p>\n\n<p>P\u00e5 VM-v\u00e4rdar tar jag h\u00e4nsyn till \u00f6verbelastning och \u201dnoisy neighbor\u201d-effekter. Jag kontrollerar om NFS- eller n\u00e4tverksf\u00f6rdr\u00f6jningar minskar nyttan av Open File Cache. \u00c4ven containerscenarier med overlay-filsystem beter sig olika beroende p\u00e5 hur de \u00e4r uppbyggda. D\u00e4rf\u00f6r m\u00e4ter jag verklig produktionsbelastning, inte bara tester p\u00e5 tomma kataloger. P\u00e5 s\u00e5 s\u00e4tt uppt\u00e4cker jag flaskhalsar tidigt och kan vidta riktade \u00e5tg\u00e4rder.<\/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>Uppf\u00f6ljning och nyckeltal: s\u00e5 m\u00e4ter jag effekten<\/h2>\n\n<p>Jag m\u00e4ter effekten genom <strong>F\u00f6rdr\u00f6jningar<\/strong>, systemanrop, I\/O-v\u00e4ntetider och arbetarresurser. Verktyg som strace, perf, iostat och nginx-status hj\u00e4lper mig att synligg\u00f6ra effekten. Jag \u00f6vervakar Time-to-First-Byte f\u00f6r statiska rutter och j\u00e4mf\u00f6r situationer med tr\u00e4ffar och missar. Genom loggarna identifierar jag \u00e5terkommande 404-v\u00e4gar eller hot directories. Parallellt kontrollerar jag <a href=\"https:\/\/webhosting.de\/sv\/file-descriptor-limit-server-hosting-tuning-server-limits\/\">Begr\u00e4nsning f\u00f6r filbeskrivare<\/a>, s\u00e5 att \u00f6ppna handlar inte fastnar vid processgr\u00e4nser.<\/p>\n\n<p>Jag registrerar m\u00e4tv\u00e4rden f\u00f6re och efter \u00f6verg\u00e5ngen. D\u00e4refter justerar jag max, inactive och valid och m\u00e4ter p\u00e5 nytt. Tv\u00e5 till tre iterationer r\u00e4cker ofta f\u00f6r att n\u00e5 ett tydligt m\u00e5lv\u00e4rde. Vid trafiktoppar kontrollerar jag om belastningskurvorna blir j\u00e4mnare. P\u00e5 s\u00e5 s\u00e4tt bel\u00e4gger jag vinsterna inte anekdotiskt, utan med entydiga <strong>Siffror<\/strong>.<\/p>\n\n<h2>Typiska fallgropar och hur man undviker dem<\/h2>\n\n<p>Jag aktiverar <strong>Cache<\/strong> Inte globalt f\u00f6r allt, utan bara d\u00e4r det ger nytta. Dynamiska slutpunkter avlastar jag p\u00e5 andra s\u00e4tt, till exempel via app-cacher eller edge-strategier. Jag v\u00e4ljer inte extremt stora max-v\u00e4rden p\u00e5 m\u00e5f\u00e5, eftersom RAM-minnet s\u00e5 sm\u00e5ningom tar slut. F\u00f6r l\u00e5nga inaktivitetsv\u00e4rden h\u00e5ller kvar \u201dd\u00f6da poster\u201d i minnet som inte l\u00e4ngre beh\u00f6vs f\u00f6r n\u00e5gra f\u00f6rfr\u00e5gningar. \u00c4ven f\u00f6r tidiga giltighetsintervall driver p\u00e5 on\u00f6diga systemanrop och f\u00f6rtar hastighetsf\u00f6rdelen.<\/p>\n\n<p>Jag fastst\u00e4ller riktlinjer f\u00f6r varje katalog och dokumenterar ansvarsf\u00f6rdelningen. Efter drifts\u00e4ttningar kontrollerar jag stickprovsvis att viktiga filer \u00e4r uppdaterade. Jag formulerar felmeddelanden tydligt s\u00e5 att 404-analyser inte f\u00f6rsvinner i bruset. Varningar i felloggen ing\u00e5r f\u00f6r mig i den regelbundna kontrollen. Med noggrann underh\u00e5llning f\u00f6rblir Open File Cache tillf\u00f6rlitlig och <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>Praktiska exempel: sm\u00e5 webbplatser kontra stora webbplatser<\/h2>\n\n<p>Jag delar in konfigurationerna efter antal filer, trafik och \u00e4ndringsfrekvens och utg\u00e5r d\u00e4rifr\u00e5n <strong>V\u00e4rden<\/strong> . Mindre projekt kr\u00e4ver f\u00e5 poster, korta inactives och m\u00e5ttliga valids. Medelstora till stora webbplatser anv\u00e4nder h\u00f6gre max-v\u00e4rden och anpassade intervall. Frekventa drifts\u00e4ttningar motiverar kortare valids, medan s\u00e4llsynta drifts\u00e4ttningar medger l\u00e4ngre. Tabellen visar typiska utg\u00e5ngspunkter som jag senare justerar utifr\u00e5n m\u00e4tningar.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Inst\u00e4llning<\/th>\n      <th>Filer (ungef\u00e4r)<\/th>\n      <th>max<\/th>\n      <th>inaktiv<\/th>\n      <th>giltig<\/th>\n      <th>min_anv\u00e4ndningar<\/th>\n      <th>Ledtr\u00e5d<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Liten webbplats<\/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>Sparsam<\/strong> starta, m\u00e4ta efter\u00e5t<\/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>-Observera topparna<\/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 sekunder<\/td>\n      <td>3+<\/td>\n      <td>RAM och I\/O \u00e4r tr\u00e5nga <strong>kontroll<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Vanliga drifts\u00e4ttningar<\/td>\n      <td>variabel<\/td>\n      <td>anpassad<\/td>\n      <td>20\u201345 sekunder<\/td>\n      <td>15\u201360 sekunder<\/td>\n      <td>2-3<\/td>\n      <td>F\u00e4rskhet f\u00f6rst <strong>Tr\u00e4fffrekvens<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Checklista f\u00f6r inf\u00f6randet<\/h2>\n\n<p>Jag f\u00f6rbereder en klar <strong>Planera<\/strong> F\u00f6rst: Definiera kataloger d\u00e4r cachelagring av metadata ger f\u00f6rdelar och avgr\u00e4nsa dynamiska zoner. D\u00e4refter anger jag konservativa startv\u00e4rden och testar konfigurationen med nginx -t. Jag startar om NGINX, \u00f6vervakar latenser och granskar loggar samt systemmetriker. D\u00e4refter justerar jag max, inactive, valid och min_uses i sm\u00e5 steg. Till sist dokumenterar jag de slutgiltiga v\u00e4rdena f\u00f6r varje milj\u00f6 och sparar \u00e4ndringarna med versionshantering.<\/p>\n\n<p>Jag har en \u00e5terst\u00e4llningsfunktion tillg\u00e4nglig ifall effekterna blir annorlunda \u00e4n f\u00f6rv\u00e4ntat. F\u00f6r \u00e5terkommande 404-s\u00f6kv\u00e4gar avg\u00f6r jag fr\u00e5n fall till fall om jag ska cacha felmeddelanden tillf\u00e4lligt. Jag beskriver ansvarsomr\u00e5den: Vem \u00e4ndrar v\u00e4rden, vem m\u00e4ter, vem godk\u00e4nner releaser. Vid drifts\u00e4ttningar med mycket media s\u00e4tter jag upp riktm\u00e4rken mot topptrafik. P\u00e5 s\u00e5 s\u00e4tt arbetar jag planm\u00e4ssigt och uppn\u00e5r h\u00e5llbara <strong>Resultat<\/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\u00e4lj till\u00e4mpningsomr\u00e5de noggrant: http, server eller plats<\/h2>\n\n<p>Jag aktiverar Open File Cache d\u00e4r det ger m\u00e4tbara f\u00f6rdelar. Att g\u00f6ra det globalt p\u00e5 HTTP-niv\u00e5 \u00e4r bekv\u00e4mt, men ofta f\u00f6r grovt. Det \u00e4r b\u00e4ttre att <strong>Scoping<\/strong> per server eller plats. P\u00e5 s\u00e5 s\u00e4tt p\u00e5verkas inte de dynamiska omr\u00e5dena, medan de statiska katalogerna drar maximal nytta av det. F\u00f6r API- eller admin-rutter st\u00e4nger jag av cachen, medan jag aktiverar den f\u00f6r resursv\u00e4gar och anpassar storleken efter behov.<\/p>\n\n<pre><code>http {\n    # Standard: avst\u00e4ngd, s\u00e5 att dynamiska zoner f\u00f6rblir neutrala\n    open_file_cache off;\n\n server {\n root \/var\/www\/site;\n\n        # Statiska tillg\u00e5ngar 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 beh\u00f6vs\n location \/api\/ {\n proxy_pass http:\/\/backend;\n }\n    }\n}<\/code><\/pre>\n\n<p>Jag b\u00f6rjar med n\u00e5gra f\u00e5, tydliga platser och ut\u00f6kar steg f\u00f6r steg. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir effekterna begripliga, och jag undviker o\u00f6nskade interaktioner mellan reglerna.<\/p>\n\n<h2>Flerprocessarkitektur: RAM och begr\u00e4nsningar i fokus<\/h2>\n\n<p>NGINX arbetar med flera <strong>Arbetare<\/strong>, och varje worker hanterar sin egen cache f\u00f6r \u00f6ppna filer. Det inneb\u00e4r att antalet max-poster multipliceras med antalet workers. Fyra workers och max=5000 inneb\u00e4r potentiellt upp till 20 000 poster i processutrymmet. Jag planerar d\u00e4rf\u00f6r RAM-minnet <em>per arbetstagare<\/em> och f\u00f6lj de faktiska kurvorna. Varje post genererar n\u00e5gra hundra byte i metadata och administrationsstrukturer, plus kostnader f\u00f6r \u00f6ppna deskriptorer.<\/p>\n\n<p>Jag l\u00e4gger dessutom fram <strong>Begr\u00e4nsningar f\u00f6r filbeskrivare<\/strong> st\u00e4ll in en l\u00e4mplig gr\u00e4ns (systemomfattande och f\u00f6r NGINX-processen). Om gr\u00e4nsen inte \u00e4r tillr\u00e4cklig kan \u00f6ppna handtag misslyckas, och cachen f\u00f6rlorar sin effekt. Jag kontrollerar ulimit -n f\u00f6r NGINX-anv\u00e4ndaren och anv\u00e4nder vid behov worker_rlimit_nofile f\u00f6r att s\u00e4kerst\u00e4lla att toppbelastningar hanteras p\u00e5 ett s\u00e4kert s\u00e4tt. Det faktiska antalet \u00f6ppna filer kontrollerar jag med lsof eller via processstatistik, f\u00f6r att inte bara uppskatta utan att veta s\u00e4kert.<\/p>\n\n<h2>Syml\u00e4nkar, alias och try_files: Detaljer med stor betydelse<\/h2>\n\n<p>I praktiken f\u00f6rekommer ofta <strong>Syml\u00e4nkar<\/strong>, alias och try_files tillsammans. Jag ser till att anv\u00e4nda alias korrekt (med r\u00e4tt slash-semantik) och undviker fallgropar. Syml\u00e4nkm\u00e5l kan \u00e4ndras vid nya versioner, medan NGINX fortfarande har metadata i cachen. Detta \u00e4r avsiktligt s\u00e5 l\u00e4nge valid-intervallet \u00e4r tillr\u00e4ckligt kort. F\u00f6r k\u00e4nsliga s\u00f6kv\u00e4gar s\u00e4krar jag dessutom med disable_symlinks if_not_owner.<\/p>\n\n<pre><code>location \/media\/ {\n    # aliaset m\u00e5ste \u00f6verensst\u00e4mma med katalogformatet (avslutande snedstreck!)\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\u00e4r det g\u00e4ller try_files anger jag tydliga fallback-v\u00e4rden och undviker kedjor som orsakar flera uppslagningar. Konsekventa s\u00f6kv\u00e4gar (root\/alias) och entydig felhantering minskar on\u00f6diga negativa tr\u00e4ffar i cachen. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir uppslagningarna snabba och transparenta.<\/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>Drifts\u00e4ttningar utan kallstart: Hantera aktualiteten<\/h2>\n\n<p>Med <strong>Ingen stillest\u00e5ndstid<\/strong>-Vid utrullningar byter jag ofta ut en symbolisk l\u00e4nk (t.ex. current \u2192 releases\/123). Open File Cache beh\u00e5ller gamla metadata fram till n\u00e4sta validering. Jag styr detta medvetet: Antingen st\u00e4ller jag in ett kortare `open_file_cache_valid` (t.ex. 5\u201315 s) runt drifts\u00e4ttningen, eller s\u00e5 startar jag om NGINX efter bytet. En omstart startar nya arbetare som bygger upp nya metadata, medan gamla arbetare hanterar f\u00f6rfr\u00e5gningarna p\u00e5 ett korrekt s\u00e4tt. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir leveransen stabil och <strong>F\u00e4rskhet<\/strong> h\u00f6g.<\/p>\n\n<p>Vid mycket stora tillg\u00e5ngsupps\u00e4ttningar kan jag d\u00e4refter identifiera \u201dheta\u201d s\u00f6kv\u00e4gar <em>v\u00e4rma upp<\/em> (t.ex. genom en kort genoms\u00f6kning) s\u00e5 att de viktigaste posterna hamnar i cachen tidigt. Jag h\u00e5ller dock detta p\u00e5 en l\u00e5g niv\u00e5 f\u00f6r att inte skapa konstgjorda I\/O-toppar.<\/p>\n\n<h2>Filsystem- och monteringsalternativ: sm\u00e5 justeringar, stor effekt<\/h2>\n\n<p>Jag \u00e4r uppm\u00e4rksam p\u00e5 <strong>noatime\/nodiratime<\/strong> vid montering av lokala volymer. P\u00e5 s\u00e5 s\u00e4tt undviks on\u00f6diga aTime-uppdateringar vid \u00e5tkomst och I\/O-belastningen minskas. F\u00f6r NFS p\u00e5verkar attributcachestrategin (t.ex. actimeo) <em>skenbar<\/em> Aktualitet \u2013 jag v\u00e4ljer v\u00e4rden som st\u00e4mmer \u00f6verens med valid f\u00f6r att undvika inkonsekvenser. F\u00f6r produktionsdata f\u00f6rlitar jag mig p\u00e5 mogna filsystem (till exempel ext4 eller xfs) och h\u00e5ller koll p\u00e5 inode-reserverna. \u00d6verfyllda eller kraftigt fragmenterade volymer kostar tid, helt oberoende av NGINX.<\/p>\n\n<p>I containrar med overlay-filsystem utv\u00e4rderar jag effekten av Open File Cache <strong>under belastning<\/strong>, inte i vilol\u00e4ge. Layering kan g\u00f6ra \u00e5tkomsten till metadata dyrare; d\u00e4rf\u00f6r justerar jag inst\u00e4llningarna f\u00f6r \u201dinactive\u201d och \u201dvalid\u201d ganska f\u00f6rsiktigt och l\u00e4gger fokus p\u00e5 hotsets.<\/p>\n\n<h2>Komprimering och statiska varianter: gzip_static, Brotli och Ranges<\/h2>\n\n<p>Jag anv\u00e4nder, n\u00e4r det \u00e4r m\u00f6jligt, <strong>gzip_static<\/strong> (och p\u00e5 samma s\u00e4tt Brotli) f\u00f6r att direkt leverera f\u00f6rkomprimerade filer. Open File Cache lagrar d\u00e5 \u00e4ven metadata f\u00f6r .gz\/.br-varianter; min_uses filtrerar bort s\u00e4llsynta specialfall. Range-f\u00f6rfr\u00e5gningar drar nytta av stabila metadata (storlek, mtime), tillsammans med sendfile och l\u00e4mpliga inst\u00e4llningar f\u00f6r tcp_nopush\/tcp_nodelay.<\/p>\n\n<pre><code>location ~* \\.(?:css|js|svg|json|txt)$ {\n    gzip_static on;  # prioritera befintliga .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>Jag ser till att ETag\/Last-Modified h\u00e5lls konsekventa. P\u00e5 s\u00e5 s\u00e4tt kan klienterna validera p\u00e5 ett effektivt s\u00e4tt, och NGINX beh\u00f6ver s\u00e4llan g\u00e5 djupt in i filsystemet. Open File Cache levererar metadata snabbt f\u00f6r detta \u00e4ndam\u00e5l.<\/p>\n\n<h2>Djupg\u00e5ende insikt och fels\u00f6kning: vad jag konkret kontrollerar<\/h2>\n\n<ul>\n  <li>Systemanrop: Som ett test kopplar jag strace till en arbetare (t.ex. -e trace=open,stat) och j\u00e4mf\u00f6r frekvensen f\u00f6re och efter aktiveringen.<\/li>\n  <li>I\/O-belastning: Kommandot `iostat -xz`, k\u00f6rt med korta intervall, visar om v\u00e4ntetiderna och k\u00f6ernas djup minskar.<\/li>\n  <li>Felaktiga s\u00f6kv\u00e4gar: Loggarna visar om \u00e5terkommande 404-fel uppst\u00e5r. Dessa s\u00f6kv\u00e4gar uppfyller kriterierna f\u00f6r tillf\u00e4lliga fel \u2013 i enskilda fall.<\/li>\n  <li>FD-gr\u00e4nser: lsof -p  | wc -l ger mig en enorm siffra som visar hur m\u00e5nga deskriptorer som \u00e4r \u00f6ppna.<\/li>\n  <li>Lagring: Jag \u00f6vervakar RSS per arbetare och korrelerar detta med max och tr\u00e4fffrekvensen f\u00f6r statiska f\u00f6rfr\u00e5gningar.<\/li>\n<\/ul>\n\n<p>Om ov\u00e4ntade f\u00f6rdr\u00f6jningar uppst\u00e5r kontrollerar jag f\u00f6rst om \u201dvalid\u201d \u00e4r f\u00f6r kort (f\u00f6r m\u00e5nga omstarter) eller om \u201dinactive\u201d \u00e4r f\u00f6r l\u00e5ngt (inaktiva poster). Jag tar bort enskilda problemkataloger fr\u00e5n cachen och m\u00e4ter p\u00e5 nytt. P\u00e5 s\u00e5 s\u00e4tt kan jag snabbt isolera orsakerna.<\/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>S\u00e4kerhetsaspekter och rena gr\u00e4nser<\/h2>\n\n<p>Jag separerar <strong>klar<\/strong> mellan offentliga och interna s\u00f6kv\u00e4gar och undviker autoindex. F\u00f6r alias och symboliska l\u00e4nkar anv\u00e4nder jag restriktiva varianter (if_not_owner) f\u00f6r att f\u00f6rhindra o\u00f6nskade genoms\u00f6kningar. Jag aktiverar felcaching endast d\u00e4r jag f\u00f6rst\u00e5r hur det fungerar. I milj\u00f6er med flera hyresg\u00e4ster isolerar jag cacher per vHost f\u00f6r att undvika \u00f6verlappningar. Tydliga gr\u00e4nser underl\u00e4ttar \u00e4ven fels\u00f6kningen, eftersom jag b\u00e4ttre kan sp\u00e5ra effekter per zon.<\/p>\n\n<h2>Ytterligare inst\u00e4llningssteg<\/h2>\n\n<p>Jag tittar \u00f6ver <strong>Filcache<\/strong> och justerar n\u00e4tverks- och TLS-parametrar. Keepalive-inst\u00e4llningar, anv\u00e4ndning av HTTP\/2 eller HTTP\/3 samt rimliga timeouts p\u00e5verkar den totala latensen avsev\u00e4rt. F\u00f6r stora filer kontrollerar jag sendfile, aio och storleken p\u00e5 utdatabuffertarna. Jag st\u00e4ller in rimliga gr\u00e4nser f\u00f6r storleken p\u00e5 rubriker och kroppstext, s\u00e5 att enstaka avvikande f\u00f6rfr\u00e5gningar inte blockerar allt. Dessutom ser jag till att loggningen \u00e4r m\u00e5linriktad f\u00f6r att minimera overheaden <strong>h\u00e5ll<\/strong>.<\/p>\n\n<p>P\u00e5 app-sidan rensar jag upp i statiska och dynamiska cacher s\u00e5 att de inte st\u00f6r varandra. Versionshantering av l\u00e5ngsiktiga tillg\u00e5ngar via hash minskar antalet omvalideringar och m\u00f6jligg\u00f6r l\u00e4ngre klientcacher. F\u00f6r API:er s\u00e4tter jag upp korta, tydliga regler och hanterar statiska filer separat. Jag separerar NGINX-instanser efter anv\u00e4ndningsfall n\u00e4r isolering ger f\u00f6rdelar. En v\u00e4lordnad konfiguration sparar tid vid drift och fels\u00f6kning.<\/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>Kortfattat sammanfattat<\/h2>\n\n<p>Med en strategiskt placerad <strong>\u00d6ppna<\/strong> Med filcachen minskar jag antalet \u00e5tkomstf\u00f6rfr\u00e5gningar till filsystemet, sparar CPU-tid och levererar statiska filer snabbare. Jag b\u00f6rjar med konservativa v\u00e4rden, m\u00e4ter de faktiska effekterna och justerar sedan stegvis inst\u00e4llningarna f\u00f6r max, inactive, valid och min_uses. Statiska kataloger gynnas av detta, medan jag utel\u00e4mnar dynamiska slutpunkter. Tillsammans med sendfile, buffertoptimering, komprimering och solida systemgr\u00e4nser h\u00f6jer jag prestandan m\u00e4rkbart. P\u00e5 s\u00e5 s\u00e4tt blir NGINX en p\u00e5litlig <strong>Bas<\/strong> f\u00f6r snabb och resurssn\u00e5l leverans.<\/p>","protected":false},"excerpt":{"rendered":"<p>St\u00e4ll in NGINX Open File Cache p\u00e5 r\u00e4tt s\u00e4tt och f\u00e5 ut b\u00e4ttre prestanda f\u00f6r din server med de b\u00e4sta inst\u00e4llningarna.<\/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":"161","_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\/sv\/wp-json\/wp\/v2\/posts\/20898","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=20898"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/20898\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/20891"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=20898"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=20898"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=20898"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}