{"id":20906,"date":"2026-08-22T18:18:36","date_gmt":"2026-08-22T16:18:36","guid":{"rendered":"https:\/\/webhosting.de\/nginx-sendfile-tcp-nopush-ratgeber-performance-setup\/"},"modified":"2026-08-22T18:18:36","modified_gmt":"2026-08-22T16:18:36","slug":"nginx-sendfile-tcp-nopush-vejledning-ydeevne-opsaetning","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/nginx-sendfile-tcp-nopush-ratgeber-performance-setup\/","title":{"rendered":"Korrekt brug af NGINX sendfile og tcp_nopush for at opn\u00e5 maksimal ydeevne"},"content":{"rendered":"<p>Med <strong>nginx sendfile<\/strong> og <strong>tcp_nopush<\/strong> Jeg leverer statiske filer med \u00bbzero-copy\u00ab fra filsystemet til socket og reducerer dermed m\u00e6rkbart b\u00e5de CPU-belastningen og antallet af pakker. N\u00e5r de er indstillet korrekt, \u00f8ger begge direktiver overf\u00f8rselseffektiviteten, mindsker overhead og danner grundlaget for en effektiv nginx-optimering af ressourcer og downloads.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>Nul-kopi<\/strong> ved hj\u00e6lp af sendfile: f\u00e6rre kopier, st\u00f8rre gennemstr\u00f8mning<\/li>\n  <li><strong>tcp_nopush<\/strong> bufferer pakker: st\u00f8rre rammer, mindre overhead<\/li>\n  <li><strong>Kombination<\/strong> t\u00e6ller: sendfile + tcp_nopush + tcp_nodelay<\/li>\n  <li><strong>Brugsscenarier<\/strong> Prioritering: statiske ressourcer, store downloads<\/li>\n  <li><strong>Test<\/strong> ved NFS\/SMB: M\u00e5l effekten, og sl\u00e5 eventuelt sendfile fra<\/li>\n<\/ul>\n\n<h2>Hvorfor sendfile frig\u00f8r s\u00e5 meget ydeevne for NGINX<\/h2>\n\n<p>Jeg aktiverer <strong>sendfile<\/strong>, fordi kernen kan sende filer direkte via netv\u00e6rksstakken uden at skulle tage en omvej via yderligere kopieringsoperationer i brugerrummet. Denne \u00bbzero-copy\u00ab-vej reducerer kontekstskift og sparer CPU-cyklusser, is\u00e6r n\u00e5r mange samtidige klienter henter statisk indhold. Store filer som billeder, CSS, JavaScript eller arkiver drager fordel af dette, fordi dataoverf\u00f8rslen foreg\u00e5r mere j\u00e6vnt og med mindre overhead. Ogs\u00e5 systemcacherne fungerer mere effektivt, da der opst\u00e5r f\u00e6rre hukommelsesbev\u00e6gelser, og kernen styrer datastr\u00f8mmen. Fordelen er mest tydelig p\u00e5 lokale filsystemer, og derfor m\u00e5ler jeg f\u00f8rst der, f\u00f8r jeg overf\u00f8rer resultaterne til mere us\u00e6dvanlige ops\u00e6tninger.<\/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\/nginx-server-setup-8934.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad tcp_nopush pr\u00e6cist g\u00f8r, og hvorn\u00e5r det virkelig kommer til sin ret<\/h2>\n\n<p>Med <strong>tcp_nopush<\/strong> Jeg beder systemet om f\u00f8rst at sende TCP-pakker, n\u00e5r de er fyldt p\u00e5 en fornuftig m\u00e5de, i stedet for at sende sm\u00e5 segmenter for tidligt. Under Linux svarer dette til TCP_CORK, under FreeBSD til TCP_NOPUSH, og i begge tilf\u00e6lde falder antallet af pakker m\u00e6rkbart. Direktivet reducerer ikke latenstiden til et minimum, men sigter mod et bedre forhold mellem nyttedata og overhead. Jeg bruger tcp_nopush m\u00e5lrettet til statiske filer, fordi sammenh\u00e6ngende datastr\u00f8mme her giver de st\u00f8rste effektivitetsgevinster. Uden sendfile har tcp_nopush ingen effekt, derfor integrerer jeg altid begge indstillinger sammen.<\/p>\n\n<h2>sendfile og tcp_nopush som par: S\u00e5dan l\u00e6gger jeg grunden<\/h2>\n\n<p>Kombinationen af <strong>sendfile<\/strong> og tcp_nopush reducerer antallet af kopier og samler pakker, hvilket g\u00f8r, at en server pr. CPU-kerne kan h\u00e5ndtere betydeligt flere parallelle overf\u00f8rsler. Jeg konfigurerer begge i http-kontekstniveauet og tilf\u00f8jer ofte tcp_nodelay, s\u00e5 den sidste rest af en datastr\u00f8m kan l\u00f8be ud uden ventetid. Det er stadig vigtigt at teste med reel trafik, da pakkest\u00f8rrelser, MTU og klienter varierer, og den bedste balance kan afvige lidt afh\u00e6ngigt af arbejdsbyrden. For statiske mapper er global aktivering som regel tilstr\u00e6kkelig, mens jeg holder \u00f8je med virkningen ved dynamiske svarruter. Denne kombination giver et solidt fundament for yderligere nginx-optimeringstrin, som kommer senere.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>direktiv<\/th>\n      <th>Form\u00e5l<\/th>\n      <th>Typisk virkning<\/th>\n      <th>Afh\u00e6ngighed<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>sendfile er aktiveret<\/strong><\/td>\n      <td>Zero-Copy fra fil til socket<\/td>\n      <td>Mindre belastning af CPU\u2019en, h\u00f8jere gennemstr\u00f8mning<\/td>\n      <td>Lokalt filsystem er ideelt<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp_nopush aktiveret<\/strong><\/td>\n      <td>Fyld pakkerne, s\u00e6nk omkostningerne<\/td>\n      <td>F\u00e6rre segmenter pr. fil<\/td>\n      <td>Fungerer kun med sendfile<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp_nodelay on<\/strong><\/td>\n      <td>Send de sidste bytes uden ventetid<\/td>\n      <td>Hurtig afslutning af overf\u00f8rslen<\/td>\n      <td>Tilf\u00f8jet tcp_nopush<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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_performance_meeting_8371.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e5dan fungerer tcp_nodelay sammen med tcp_nopush<\/h2>\n\n<p>Jeg aktiverer <strong>tcp_nopush<\/strong>, for at sende starten af en overf\u00f8rsel i st\u00f8rre pakker, og tillad samtidig tcp_nodelay, s\u00e5 afslutningen ikke g\u00e5r i st\u00e5. Begge indstillinger p\u00e5virker forskellige faser af datastr\u00f8mmen og forstyrrer ikke hinanden, n\u00e5r NGINX leverer filer via sendfile. Is\u00e6r ved mange sm\u00e5 filer forhindrer tcp_nodelay, at klienten venter un\u00f8digt p\u00e5 grund af sm\u00e5 resterende datam\u00e6ngder. Jeg tester f\u00f8rst kombinationen i staging, overv\u00e5ger RTT\u2019er og segmentst\u00f8rrelser og sammenligner dem med live-metrikker. P\u00e5 den m\u00e5de sikrer jeg effektivitet i starten og hurtighed i slutningen af overf\u00f8rslen.<\/p>\n\n<pre><code>http {\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n}\n<\/code><\/pre>\n\n<h2>Typiske anvendelsesscenarier: hvor direktiverne har stor indflydelse<\/h2>\n\n<p>Ved store <strong>Downloads<\/strong> Ligesom videoer, arkiver eller ISO-billeder reducerer kernels \u00bbzero-copy-path\u00ab CPU-tiden pr. overf\u00f8rsel markant. I CDN-lignende ops\u00e6tninger med mange CSS-, JS- og fontfiler sparer tcp_nopush segmenter og \u00f8ger dermed den anvendelige b\u00e5ndbredde pr. socket. P\u00e5 WordPress-sider med god caching vedr\u00f8rer de fleste anmodninger statiske ressourcer, hvorfor jeg meget hurtigt kan se effekten der. Ogs\u00e5 build-artefakter, container-images eller installationsprogrammer drager fordel heraf, forudsat at de ligger lokalt og ikke kommer via et ustabilt netv\u00e6rksfilsystem. Hvis man forventer belastningsspidser, kan man med denne kombination f\u00e5 meget stabilitet ud af den eksisterende hardware.<\/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-performance-optimization-2378.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktisk eksempel: NGINX til WordPress med caching og ressourcer<\/h2>\n\n<p>I WordPress-ops\u00e6tninger inds\u00e6tter jeg <strong>sendfile<\/strong>, tcp_nopush og tcp_nodelay globalt, leverer statiske ressourcer direkte og holder PHP-FPM adskilt fra dynamiske stier. Jeg tilf\u00f8jer relevante cache-headere til billeder, CSS og JavaScript, s\u00e5 browsere foretager f\u00e6rre roundtrips. N\u00e5r jeg leverer streaming-lignende svar, tager jeg h\u00f8jde for interaktionen med buffering og tester, hvordan chunk-st\u00f8rrelser p\u00e5virker latenstid og gennemstr\u00f8mning; dette passer godt sammen med oversigten over <a href=\"https:\/\/webhosting.de\/da\/http-svar-streaming-hosting-performance-chunks\/\">Streaming af svar i bidder<\/a>. Til tekstbaseret indhold anvender jeg komprimering uden at pakke bin\u00e6re filer un\u00f8digt. P\u00e5 den m\u00e5de forbliver anmodningsstr\u00f8mmen stabil, CPU\u2019en aflastet og tiden til f\u00f8rste byte kort.<\/p>\n\n<pre><code>http {\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n\n keepalive_timeout 65;\n    gzip on;\n    gzip_types text\/css application\/javascript image\/svg+xml;\n\n    server {\n listen 80;\n server_name blog.example.com;\n root \/var\/www\/blog;\n\n location \/ {\n try_files $uri $uri\/ \/index.php?$args;\n }\n\n        location ~ \\.php$ {\n include fastcgi_params;\n fastcgi_pass unix:\/run\/php\/php-fpm.sock;\n            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n }\n\n location ~* \\.(jpg|jpeg|png|gif|css|js|ico|svg|woff2?)$ {\n expires 30d;\n add_header Cache-Control \"public, max-age=2592000\";\n }\n    }\n}\n<\/code><\/pre>\n\n<h2>N\u00e5r jeg bevidst deaktiverer sendfile<\/h2>\n\n<p>Jeg skifter <strong>sendfile<\/strong> hvis filerne ligger p\u00e5 NFS, SMB eller distribuerede filsystemer, som i min test giver d\u00e5rligere gennemstr\u00f8mning. Visse drivere eller forsinkelser i lagringsstien kan oph\u00e6ve fordelen ved zero-copy, hvorfor m\u00e5linger er afg\u00f8rende. Ved sporadiske netv\u00e6rksproblemer deaktiverer jeg f\u00f8rst tcp_nopush for at indkredse \u00e5rsagerne, f\u00f8r jeg selv unders\u00f8ger sendfile. Ogs\u00e5 us\u00e6dvanlige kernel-bugs eller \u00e6ldre stakke kan v\u00e6re grunde til midlertidigt at skifte til den klassiske l\u00e6se-skrive-sti. Det er vigtigt at implementere \u00e6ndringer trinvist og underbygge dem med m\u00e5linger.<\/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_3456.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Fejlkilder, som jeg holder \u00f8je med<\/h2>\n\n<p>Jeg tjekker f\u00f8rst, om <strong>tcp_nopush<\/strong> er aktiveret ved en fejl, mens sendfile forbliver deaktiveret, da indstillingen i s\u00e5 fald ikke har nogen effekt. Ved dynamiske stier holder jeg \u00f8je med, om yderligere buffering \u00f8ger latenstiden, og afvejer fordelene i forhold til responstiden. P\u00e5 netv\u00e6rk med h\u00f8j latenstid m\u00e5ler jeg, om st\u00f8rre pakker virkelig hj\u00e6lper, eller om jeg skal finjustere segmentst\u00f8rrelser og keep-alive. Ogs\u00e5 MTU-konfigurationen og netv\u00e6rkskortets offloading-funktioner kan synligt p\u00e5virke resultatet. Overskuelige logfiler, pcap-pr\u00f8ver og korrelerede systemmetrikker viser mig hurtigt, hvor jeg skal foretage justeringer.<\/p>\n\n<h2>En helhedsorienteret tilgang til NGINX-ydeevne: yderligere justeringsmuligheder<\/h2>\n\n<p>Ud over <strong>sendfile<\/strong> Det l\u00f8nner sig at indstille det korrekte antal worker_processes og worker_connections, s\u00e5 jeg ikke kunstigt begr\u00e6nser antallet af sockets. Under Linux bruger jeg epoll og s\u00f8rger for tilstr\u00e6kkelige filbeskrivere, s\u00e5 belastningsspidser ikke f\u00f8rer til flaskehalse. For tekstindhold aktiverer jeg gzip eller Brotli og tester, om komprimeringsniveauet belaster CPU\u2019en p\u00e5 en fornuftig m\u00e5de. P\u00e5 transportniveau holder jeg forbindelserne \u00e5bne l\u00e6ngere og optimerer Keep-Alive, hvilket vejledningen <a href=\"https:\/\/webhosting.de\/da\/http-keep-alive-tuning-serverbelastning-ydeevneoptimering-flow\/\">Keep-Alive-tuning<\/a> giver praktiske retningslinjer. TLS, genbrug af sessioner samt HTTP\/2 eller HTTP\/3 fuldender ops\u00e6tningen og underst\u00f8tter h\u00f8j parallelitet med moderat latenstid.<\/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_4203.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Begr\u00e6nsninger og s\u00e6rlige tilf\u00e6lde: TLS, HTTP\/2\/3 og proxying<\/h2>\n\n<p>Jeg tager h\u00f8jde for, at <strong>sendfile<\/strong> g\u00e6lder teknisk set kun for ukrypterede filstier eller specifikke kernefunktioner. Ved klassisk TLS krypterer NGINX bytes i brugerrummet, hvorfor fordelen ved zero-copy bortfalder; moderne kerneler kan delvist flytte krypteringen ind i kernelen, hvilket gendanner effekten, men dette er ikke tilg\u00e6ngeligt i alle ops\u00e6tninger. Ved <strong>HTTP\/2<\/strong> Dataene ligger i frames, flere svar deler en TCP-forbindelse, og NGINX ompakker aktivt bytes \u2013 her er sendfile mindre relevant. <strong>HTTP\/3<\/strong> er baseret p\u00e5 UDP\/QUIC og f\u00f8lger igen andre regler, s\u00e5 jeg snarere opn\u00e5r effektivitetsgevinster gennem buffere, overbelastningskontrol og korrekt valgte chunk-st\u00f8rrelser. Som <strong>Omvendt proxy<\/strong> sendfile fungerer kun, hvis jeg rent faktisk serverer filer fra det lokale filsystem; svar fra <em>proxy_pass<\/em> eller <em>fastcgi_pass<\/em> De passerer alligevel gennem brugerrummet. Derfor adskiller jeg assets strengt fra den dynamiske sti, s\u00e5 zero-copy-metoden udnyttes maksimalt.<\/p>\n\n<h2>S\u00e5dan v\u00e6lger du den rigtige komprimering: gzip\/Brotli kontra gzip_static<\/h2>\n\n<p>N\u00e5r NGINX komprimerer indhold i realtid, skal det l\u00e6se filen, behandle den og skrive resultatet \u2013 og i den forbindelse g\u00e5r <strong>sendfile<\/strong> sin fordel. Til statiske ressourcer bruger jeg derfor, hvor det er muligt, <em>forh\u00e5ndskomprimeret<\/em> Filer (f.eks. .gz eller .br) og lader dem leveres direkte. P\u00e5 den m\u00e5de bevares Zero-Copy-stien, fordi NGINX kan videregive den forkomprimerede fil p\u00e5 samme m\u00e5de som ethvert andet medie. For teksttunge indholdselementer, der sj\u00e6ldent \u00e6ndres, opn\u00e5r jeg p\u00e5 denne m\u00e5de CPU-besparelser og stabil gennemstr\u00f8mning uden at g\u00e5 p\u00e5 kompromis med overf\u00f8rselstiden. Ved bin\u00e6re filer og allerede komprimerede formater undg\u00e5r jeg enhver komprimering under k\u00f8rsel \u2013 her t\u00e6ller ren I\/O-gennemstr\u00f8mning, og sendfile samt tcp_nopush udnytter deres styrker fuldt ud.<\/p>\n\n<h2>AIO, directio og Page Cache: M\u00f8nstre for sm\u00e5 og store filer<\/h2>\n\n<p>Jeg kombinerer <strong>sendfile<\/strong> med asynkron I\/O og direkte diskadgang for at opn\u00e5 det optimale resultat afh\u00e6ngigt af filst\u00f8rrelsen. Sm\u00e5 til mellemstore filer drager fordel af kernels sidecache og forbliver p\u00e5 sendfile-stien. Meget store filer kan derimod fortr\u00e6nge cachen; i s\u00e5 fald l\u00e6ser jeg dem m\u00e5lrettet med <em>Direktion<\/em> uden for cachen og arbejder med AIO-tr\u00e5de. P\u00e5 den m\u00e5de aflaster jeg hukommelsen og holder ventetiden lav for andre anmodninger. Et typisk m\u00f8nster ser s\u00e5dan ud:<\/p>\n\n<pre><code>http {\n    # Standardsti: Zero-Copy fra sidecachen\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n\n # Store filer: uden om cachen og asynkron l\u00e6sning\n    aio threads;\n    directio 4m; # g\u00e6lder kun for filer &gt;= 4 MiB\n    output_buffers 1 512k;    # Buffer til directio-stier\n    sendfile_max_chunk 1m;    # Retf\u00e6rdighed under h\u00f8j belastning\n}\n<\/code><\/pre>\n\n<p>Med denne differentiering forbliver sm\u00e5 filer ekstremt effektive, mens meget store overf\u00f8rsler ikke overbelaster arbejdshukommelsen. Vigtigt: directio deaktiverer sendfile-stien for de ber\u00f8rte filer \u2013 og det er pr\u00e6cis, hvad jeg har til hensigt i forbindelse med anvendelsen af store filer.<\/p>\n\n<h2>Retf\u00e6rdighed og str\u00f8mningskontrol under belastning<\/h2>\n\n<p>I perioder med h\u00f8j belastning vil jeg gerne undg\u00e5, at en enkelt stream monopoliserer CPU\u2019en eller soklen. Jeg indstiller <strong>sendfile_max_chunk<\/strong>, s\u00e5 NGINX returnerer kontrollen til kernen efter en bestemt m\u00e6ngde bytes og giver plads til andre forbindelser. Til b\u00e5ndbreddestyring hj\u00e6lper <em>limit_rate<\/em> og <em>limit_rate_after<\/em>, f.eks. for at begr\u00e6nse bulk-downloads, mens UI-elementer forbliver hurtige. Med <em>uds\u00e6t_output<\/em> Jeg styrer, fra hvilken svarst\u00f8rrelse NGINX begynder at sende \u2013 i kombination med tcp_nopush sikrer jeg dermed p\u00e6ne pakkeopdelinger. Derudover er jeg opm\u00e6rksom p\u00e5 <em>lingering_close<\/em>, s\u00e5 de resterende pakker kan afvikles korrekt, og soklen ikke afbrydes brat.<\/p>\n\n<h2>Filsystemer, readahead og lagringsstier<\/h2>\n\n<p>Fordi <strong>sendfile<\/strong> N\u00e5r man bruger sidecaches, spiller det underliggende filsystem en stor rolle. Jeg tjekker readahead-v\u00e6rdierne og indstiller dem s\u00e5ledes, at sekventielle l\u00e6seoperationer p\u00e5 store filer ikke g\u00e5r i st\u00e5, uden at det g\u00e5r ud over de mindre filer. P\u00e5 <em>ext4<\/em> eller <em>xfs<\/em> Jeg observerer, hvor godt prefetching og I\/O-scheduler passer til mit gennemstr\u00f8mningsm\u00f8nster. P\u00e5 netv\u00e6rksfiler (NFS\/SMB) tester jeg rsize\/wsize, caching og latenstider grundigt, fordi selv sm\u00e5 afvigelser neutraliserer Zero-Copy-fordelen. Min regel er stadig: F\u00f8rst skal de lokale stier udnyttes maksimalt, derefter skal eksterne stakke justeres forsigtigt \u2013 og m\u00e5lev\u00e6rdier skal altid veje tungere end mavefornemmelsen.<\/p>\n\n<h2>Pragmatisk tilpasning af netv\u00e6rksstakken og NIC-offloading<\/h2>\n\n<p>Ved et stort antal forbindelser stoler jeg p\u00e5 den automatiske buffertilpasning i moderne stakke, men justerer sende- og modtagelsesbufferne efter behov. NIC-offloads som TSO, GSO og GRO reducerer CPU-belastningen m\u00e6rkbart; i m\u00e5linger er jeg dog forsigtig, da pakkeoptagelser kan virke forvr\u00e6ngede p\u00e5 grund af offloading (tilsyneladende f\u00e5, meget store segmenter). Derfor korrelerer jeg <em>pcap<\/em>\u2011Traces med m\u00e5linger fra NGINX og kernen for at skelne mellem reelle netv\u00e6rksst\u00f8rrelser og offload-artefakter. Ved latenstops afbryder jeg kortvarigt testene med deaktiverede offloads, dokumenterer forskellen og beslutter derefter, hvad der giver st\u00f8rst fordel i kontinuerlig drift.<\/p>\n\n<h2>Konfigurationsskabeloner pr. lokation: m\u00e5lrettet aktivering og deaktivering<\/h2>\n\n<p>Jeg holder muligheden \u00e5ben for, <strong>sendfile<\/strong> afh\u00e6ngigt af stien eller filtypen. For statiske mapper forbliver den aktiveret, mens jeg for streaming- eller dynamiske stier sl\u00e5r den selektivt fra, n\u00e5r buffere eller filtre (f.eks. komprimering) har forrang. Et kort eksempel:<\/p>\n\n<pre><code>server {\n    listen 80;\n    server_name static.example.com;\n    root \/var\/www\/static;\n\n # Statiske ressourcer: Zero-Copy\n    location \/assets\/ {\n sendfile on;\n tcp_nopush on;\n        tcp_nodelay on;\n expires 7d;\n    }\n\n # Dynamik eller streaming: Fleksibilitet frem for Zero-Copy\n    location \/api\/ {\n sendfile off;\n proxy_pass http:\/\/app_upstream;\n    }\n}\n<\/code><\/pre>\n\n<p>Denne adskillelse forhindrer, at jeg mister fordele p\u00e5 den ene side, blot fordi en anden vej stiller s\u00e6rlige krav.<\/p>\n\n<h2>Range, Slices og store kataloger<\/h2>\n\n<p>N\u00e5r det drejer sig om store objekter, spiller <strong>R\u00e6kkevidde<\/strong>-anmodninger udnytter deres styrker: Klienten indl\u00e6ser kun de n\u00f8dvendige dele, og forbindelserne forbliver stabile. I indholdskataloger med meget store filer foretr\u00e6kker jeg at opdele overf\u00f8rslerne logisk \u2013 serverbelastningen fordeles mere j\u00e6vnt, og fejl som afbrud koster mindre tid. I caching-scenarier forebygger jeg \u201eThundering Herds\u201c ved at buffe svarene p\u00e5 en fornuftig m\u00e5de, men uden kunstigt at tilbageholde sm\u00e5 chunks og restdata. Samspillet med tcp_nopush er her afg\u00f8rende: Jeg holder de indledende segmenter store, men lader ikke slutningen vente.<\/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-5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>M\u00e5le- og teststrategi: P\u00e5lidelig p\u00e5visning af effekter<\/h2>\n\n<p>Jeg underbygger optimeringer med reproducerbare tests. P\u00e5 serversiden overv\u00e5ger jeg CPU-profiler, <em>$request_time<\/em>, <em>1 TP 4 Tbyte sendt<\/em>, aktive forbindelser og kontekstskift. P\u00e5 netv\u00e6rket m\u00e5ler jeg segmentst\u00f8rrelser, retransmissioner og RTT-fordeling; jeg korrelerer pakkefangster med socket-statistikker for at tage h\u00f8jde for offload-effekter. P\u00e5 klientsiden sammenligner jeg TTFB, First Contentful Paint og downloadtider under realistiske RTT-v\u00e6rdier og b\u00e5ndbredder. Jeg varierer MTU, Keep-Alive-indstillinger og filst\u00f8rrelser, s\u00e5 jeg ikke kun ser \u00bbbest-case\u00ab-kurver. Til sidst beslutter jeg p\u00e5 baggrund af konkrete tal, om sendfile\/tcp_nopush leverer den \u00f8nskede stabilitet og effektivitet i den p\u00e5g\u00e6ldende arbejdsbelastning \u2013 og finjusterer, indtil det er tilf\u00e6ldet.<\/p>\n\n<h2>HTTP-detaljer, der g\u00f8r en forskel: Range og streaming<\/h2>\n\n<p>Jeg bruger <strong>R\u00e6kkevidde<\/strong>-Anmodninger ved store filer, s\u00e5 klienterne kun henter de n\u00f8dvendige dele, og forbindelserne forbliver stabile. Is\u00e6r ved video-spoling og genoptagelse af opdateringer hj\u00e6lper en velfungerende underst\u00f8ttelse af byterange med at fordele b\u00e5ndbredden hensigtsm\u00e6ssigt; yderligere oplysninger findes p\u00e5 siden om <a href=\"https:\/\/webhosting.de\/da\/http-range-requests-media-and-download-hosting-performance-byte\/\">HTTP-Range-anmodninger<\/a>. For l\u00f8bende svar med en voksende br\u00f8dtekst tester jeg streaming-strategier og s\u00f8rger for, at buffere ikke utilsigtet holder fast i dataene for l\u00e6nge. I den forbindelse respekterer jeg cacher og inds\u00e6tter relevante headere, s\u00e5 proxyservere og browsere fungerer korrekt. Jeg tager h\u00f8jde for samspillet med tcp_nopush, da pakkest\u00f8rrelser og timingen af flush har direkte indflydelse p\u00e5 den oplevede hastighed.<\/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-5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Med <strong>sendfile<\/strong> Jeg videresender filer effektivt direkte til kernen, og med tcp_nopush s\u00f8rger jeg for, at pakkerne udfyldes optimalt, inden de belaster forbindelsen. Begge direktiver supplerer hinanden, mens tcp_nodelay leverer den sidste restbyte uden forsinkelse. Jeg tester effekten under reel trafik, holder \u00f8je med lagringssti, MTU, Keep-Alive og komprimering og foretager konsekvente m\u00e5linger. For WordPress- og CDN-lignende arbejdsbelastninger viser fordelene sig s\u00e6rligt hurtigt, fordi mange anmodninger vedr\u00f8rer statiske ressourcer. Den, der anvender indstillingerne m\u00e5lrettet, opn\u00e5r st\u00f8rre gennemstr\u00f8mning pr. kerne, reducerer overhead og skaber reserver til reelle v\u00e6kstspidser.<\/p>","protected":false},"excerpt":{"rendered":"<p>Praktisk vejledning til konfiguration af NGINX sendfile og tcp_nopush for at opn\u00e5 maksimal ydeevne ved levering af statiske filer og store downloads.<\/p>","protected":false},"author":1,"featured_media":20899,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20906","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":"133","_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 sendfile","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":"20899","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20906","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=20906"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20906\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20899"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20906"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20906"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20906"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}