{"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-handleiding-prestaties-configuratie","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/nginx-sendfile-tcp-nopush-ratgeber-performance-setup\/","title":{"rendered":"NGINX sendfile en tcp_nopush correct gebruiken voor maximale prestaties"},"content":{"rendered":"<p>Met <strong>nginx sendfile<\/strong> en <strong>tcp_nopush<\/strong> Ik lever statische bestanden via zero-copy vanuit het bestandssysteem naar de socket, waardoor zowel de CPU-belasting als het aantal pakketten merkbaar afneemt. Als ze correct zijn ingesteld, verhogen beide richtlijnen de effici\u00ebntie van de overdracht, verlagen ze de overhead en leggen ze de basis voor een vlekkeloze nginx-optimalisatie bij assets en downloads.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>Nul-kopie<\/strong> via sendfile: minder kopie\u00ebn, meer doorvoercapaciteit<\/li>\n  <li><strong>tcp_nopush<\/strong> buffert pakketten: grotere frames, minder overhead<\/li>\n  <li><strong>Combinatie<\/strong> telt: sendfile + tcp_nopush + tcp_nodelay<\/li>\n  <li><strong>Gebruikscases<\/strong> prioriteit geven aan: statische bestanden, grote downloads<\/li>\n  <li><strong>Tests<\/strong> bij NFS\/SMB: effect meten, indien nodig sendfile uitschakelen<\/li>\n<\/ul>\n\n<h2>Waarom sendfile zoveel prestaties vrijmaakt voor NGINX<\/h2>\n\n<p>Ik activeer <strong>sendfile<\/strong>, omdat de kernel bestanden rechtstreeks via de netwerkstack kan verzenden, zonder de omweg via extra kopieerbewerkingen in de gebruikersruimte. Dit zero-copy-pad vermindert contextwisselingen en bespaart CPU-cycli, vooral wanneer veel gelijktijdige clients statische inhoud ophalen. Grote bestanden zoals afbeeldingen, CSS, JavaScript of archieven profiteren hiervan, omdat de gegevensoverdracht gelijkmatiger verloopt en minder overhead met zich meebrengt. Ook de systeemcaches werken effici\u00ebnter, omdat er minder geheugenverplaatsingen plaatsvinden en de kernel de route van de gegevens bepaalt. Op lokale bestandssystemen is het voordeel het duidelijkst zichtbaar, daarom meet ik daar eerst voordat ik de resultaten naar exotische opstellingen toepas.<\/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>Wat tcp_nopush precies doet en wanneer het uitblinkt<\/h2>\n\n<p>Met <strong>tcp_nopush<\/strong> Ik vraag het systeem om TCP-pakketten pas te verzenden als ze voldoende gevuld zijn, in plaats van te vroeg kleine segmenten te versturen. Onder Linux komt dit overeen met TCP_CORK, onder FreeBSD met TCP_NOPUSH, en in beide gevallen neemt het aantal pakketten meetbaar af. De richtlijn brengt de latentie niet tot een minimum, maar streeft naar een betere verhouding tussen gebruiksgegevens en overhead. Ik gebruik tcp_nopush specifiek bij statische bestanden, omdat samenhangende gegevensstromen daar de grootste effici\u00ebntiewinst opleveren. Zonder sendfile heeft tcp_nopush geen effect, daarom neem ik beide instellingen altijd samen op.<\/p>\n\n<h2>sendfile en tcp_nopush als duo: zo leg ik de basis<\/h2>\n\n<p>De combinatie van <strong>sendfile<\/strong> en tcp_nopush vermindert het aantal kopie\u00ebn en bundelt pakketten, waardoor een server per CPU-kern aanzienlijk meer parallelle overdrachten aankan. Ik configureer beide op het http-contextniveau en voeg vaak tcp_nodelay toe, zodat het laatste restje van een flow zonder wachttijd wordt afgevoerd. Het blijft belangrijk om te testen met echt verkeer, aangezien pakketgroottes, MTU en clients vari\u00ebren en de beste balans afhankelijk van de workload enigszins kan verschillen. Voor statische mappen volstaat meestal de globale activering, terwijl ik bij dynamische antwoordroutes let op het effect. Deze combinatie vormt een solide basis voor verdere nginx-optimalisatiestappen, die later hierop voortbouwen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>richtlijn<\/th>\n      <th>Doel<\/th>\n      <th>Typisch effect<\/th>\n      <th>Afhankelijkheid<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>sendfile aan<\/strong><\/td>\n      <td>Zero-copy van bestand naar socket<\/td>\n      <td>Minder belasting van de CPU, hogere doorvoersnelheid<\/td>\n      <td>Lokaal bestandssysteem is ideaal<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp_nopush aan<\/strong><\/td>\n      <td>Pakketten vullen, overheadkosten verlagen<\/td>\n      <td>Minder segmenten per bestand<\/td>\n      <td>Werkt alleen met sendfile<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp_nodelay aan<\/strong><\/td>\n      <td>Laatste bytes verzenden zonder te wachten<\/td>\n      <td>Snelle afronding van de overdracht<\/td>\n      <td>tcp_nopush toegevoegd<\/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>Zo werkt tcp_nodelay samen met tcp_nopush<\/h2>\n\n<p>Ik activeer <strong>tcp_nopush<\/strong>, om het begin van een overdracht in grotere pakketten te verzenden, en laat tegelijkertijd tcp_nodelay toe, zodat de afronding niet vastloopt. Beide instellingen hebben invloed op verschillende fasen van de datastroom en hinderen elkaar niet wanneer NGINX bestanden via sendfile verzendt. Vooral bij veel kleine bestanden voorkomt tcp_nodelay dat de client onnodig moet wachten vanwege kleine restgegevens. Ik test de combinatie eerst in de staging-omgeving, houd de RTT\u2019s en segmentgroottes in de gaten en vergelijk deze met live-statistieken. Zo zorg ik voor effici\u00ebntie aan het begin en snelheid aan het einde van de overdracht.<\/p>\n\n<pre><code>http {\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n}\n<\/code><\/pre>\n\n<h2>Typische toepassingsscenario\u2019s: waar de richtlijnen een sterk effect hebben<\/h2>\n\n<p>Voor grote <strong>Downloads<\/strong> Net als bij video\u2019s, archieven of ISO-images vermindert het zero-copy-pad van de kernel de CPU-tijd per overdracht aanzienlijk. In CDN-achtige opstellingen met veel CSS-, JS- en lettertypebestanden bespaart tcp_nopush segmenten en vergroot zo de bruikbare bandbreedte per socket. Op WordPress-sites met een goede cache hebben de meeste verzoeken betrekking op statische assets, waardoor ik het effect daar al snel zie. Ook build-artefacten, containerimages of installatieprogramma\u2019s profiteren hiervan, mits ze lokaal zijn opgeslagen en niet via een onstabiel netwerkbestandssysteem worden aangevoerd. Wie pieken in de belasting verwacht, haalt met dit duo veel stabiliteit uit de beschikbare 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>Praktijkvoorbeeld: NGINX voor WordPress met caching en assets<\/h2>\n\n<p>In WordPress-installaties gebruik ik <strong>sendfile<\/strong>, tcp_nopush en tcp_nodelay globaal ingesteld, lever ik statische bronnen direct aan en houd ik PHP-FPM strikt gescheiden voor dynamische paden. Ik voeg zinvolle cache-headers toe voor afbeeldingen, CSS en JavaScript, zodat browsers minder roundtrips hoeven te maken. Wanneer ik streaming-achtige antwoorden lever, houd ik rekening met de interactie met buffering en test ik hoe chunkgroottes de latentie en doorvoer be\u00efnvloeden; het overzicht bij <a href=\"https:\/\/webhosting.de\/nl\/http-reactie-streaming-hosting-prestatie-brokken\/\">Antwoordstroom in brokken<\/a>. Voor op tekst gebaseerde inhoud maak ik gebruik van compressie, zonder binaire bestanden onnodig te comprimeren. Zo blijft de verzoekstroom stabiel, wordt de CPU ontlast en blijft de time-to-first-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>Wanneer ik sendfile bewust uitschakel<\/h2>\n\n<p>Ik schakel in <strong>sendfile<\/strong> wanneer bestanden via NFS, SMB of gedistribueerde bestandssystemen worden opgeslagen, die in mijn test een lagere doorvoersnelheid opleveren. Sommige stuurprogramma\u2019s of vertragingen in het opslagpad doen het voordeel van zero-copy teniet, waardoor metingen de doorslag geven. Bij sporadische netwerkeigenaardigheden schakel ik eerst tcp_nopush uit om de effecten te beperken, voordat ik sendfile zelf in twijfel trek. Ook ongebruikelijke kernelbugs of verouderde stacks kunnen redenen zijn om tijdelijk over te schakelen naar het klassieke lees-schrijfpad. Het blijft belangrijk om wijzigingen stapsgewijs door te voeren en deze met statistieken te onderbouwen.<\/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>Bronnen van fouten waar ik op let<\/h2>\n\n<p>Ik controleer eerst of <strong>tcp_nopush<\/strong> per ongeluk is ingeschakeld, terwijl sendfile uitgeschakeld blijft, want dan heeft de instelling geen effect. Bij dynamische paden kijk ik of extra buffering de latentie verhoogt en weeg ik het voordeel af tegen de reactietijd. Bij netwerken met hoge latentie meet ik of grotere pakketten echt helpen of dat ik moet sleutelen aan segmentgroottes en keep-alive. Ook de MTU-configuratie en offloading-functies van de netwerkkaart kunnen het resultaat merkbaar be\u00efnvloeden. Overzichtelijke logbestanden, pcap-samples en gecorreleerde systeemstatistieken laten me snel zien waar ik aanpassingen moet doen.<\/p>\n\n<h2>Een holistische benadering van de prestaties van NGINX: andere instelmogelijkheden<\/h2>\n\n<p>Naast <strong>sendfile<\/strong> Het loont de moeite om het juiste aantal `worker_processes` en `worker_connections` in te stellen, zodat ik het aantal sockets niet kunstmatig beperk. Onder Linux gebruik ik epoll en zorg ik voor voldoende bestandsdescriptoren, zodat pieken in de belasting niet tot knelpunten leiden. Voor tekstinhoud schakel ik gzip of Brotli in en test ik of het compressieniveau de CPU op een zinvolle manier belast. Op transportniveau houd ik verbindingen langer open en optimaliseer ik Keep-Alive, waarvoor de handleiding <a href=\"https:\/\/webhosting.de\/nl\/http-keep-alive-tuning-serverbelasting-prestatieoptimalisatie-flow\/\">Keep-Alive-tuning<\/a> biedt praktische richtlijnen. TLS, hergebruik van sessies en HTTP\/2 of HTTP\/3 maken de configuratie compleet en ondersteunen een hoge mate van parallelliteit met een gematigde latentie.<\/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>Beperkingen en uitzonderingsgevallen: TLS, HTTP\/2\/3 en proxying<\/h2>\n\n<p>Ik houd er rekening mee dat <strong>sendfile<\/strong> technisch gezien alleen van toepassing is op onversleutelde bestandspaden of specifieke kernel-functies. Bij klassieke TLS versleutelt NGINX de bytes in de gebruikersruimte, waardoor het zero-copy-voordeel wegvalt; moderne kernels kunnen de versleuteling gedeeltelijk naar de kernel verplaatsen, wat het effect weer terugbrengt, maar dit is niet in elke opstelling beschikbaar. Bij <strong>HTTP\/2<\/strong> de gegevens zitten in frames, meerdere antwoorden delen \u00e9\u00e9n TCP-verbinding en NGINX herschikt de bytes actief \u2013 in dit geval is sendfile minder relevant. <strong>HTTP\/3<\/strong> is gebaseerd op UDP\/QUIC en volgt weer andere regels, zodat ik effici\u00ebntiewinst vooral bereik via buffers, congestiebeheersing en correct gekozen chunkgroottes. Als <strong>Omgekeerde proxy<\/strong> sendfile werkt alleen als ik daadwerkelijk bestanden vanuit het lokale bestandssysteem verstrek; antwoorden uit <em>proxy_pass<\/em> of <em>fastcgi_pass<\/em> die gaan sowieso via de gebruikersruimte. Daarom houd ik assets strikt gescheiden van het dynamische pad, zodat er optimaal gebruik wordt gemaakt van de zero-copy-methode.<\/p>\n\n<h2>Compressie op de juiste manier inperken: gzip\/Brotli versus gzip_static<\/h2>\n\n<p>Zodra NGINX inhoud direct comprimeert, moet het het bestand lezen, verwerken en het resultaat opslaan \u2013 daarbij gaat <strong>sendfile<\/strong> zijn voordeel. Voor statische assets gebruik ik daarom, waar mogelijk, <em>vooraf gecomprimeerd<\/em> Bestanden (bijv. .gz of .br) en laat ze direct doorsturen. Zo blijft het zero-copy-traject behouden, omdat NGINX het vooraf gecomprimeerde bestand net als elk ander bestand kan doorgeven. Voor tekstrijke, zelden gewijzigde inhoud bereik ik zo CPU-besparing en een stabiele doorvoer, zonder in te boeten aan overdrachtstijd. Bij binaire bestanden en reeds gecomprimeerde formaten bespaar ik elke vorm van runtime-compressie \u2013 hier telt puur I\/O-doorvoervermogen, en sendfile plus tcp_nopush komen hier goed tot hun recht.<\/p>\n\n<h2>AIO, directio en Page Cache: patronen voor kleine en grote bestanden<\/h2>\n\n<p>Ik combineer <strong>sendfile<\/strong> met asynchrone I\/O en directe schijftoegang, om afhankelijk van de bestandsgrootte het optimale resultaat te bereiken. Kleine tot middelgrote bestanden profiteren van de paginacache van de kernel en blijven op het sendfile-pad. Zeer grote bestanden kunnen daarentegen de cache verdringen; in dat geval lees ik ze gericht met <em>directio<\/em> buiten de cache en werk ik met AIO-threads. Hierdoor ontlast ik het geheugen en houd ik de latentie voor andere verzoeken laag. Een typisch patroon ziet er als volgt uit:<\/p>\n\n<pre><code>http {\n    # Standaardpad: zero-copy vanuit de paginacache\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n\n # Grote bestanden: om de cache heen en asynchroon lezen\n    aio threads;\n    directio 4m; # is alleen van toepassing op bestanden &gt;= 4 MiB\n    output_buffers 1 512k;    # Buffers voor directio-paden\n    sendfile_max_chunk 1m;    # Eerlijke verdeling bij hoge belasting\n}\n<\/code><\/pre>\n\n<p>Met deze schaalverdeling blijven kleine bestanden uiterst effici\u00ebnt, terwijl zeer grote overdrachten het werkgeheugen niet overbelasten. Belangrijk: directio schakelt voor de betreffende bestanden het sendfile-pad uit \u2013 precies zoals ik het voor het gebruiksscenario met grote bestanden voor ogen heb.<\/p>\n\n<h2>Eerlijkheid en stroomregeling onder belasting<\/h2>\n\n<p>Tijdens periodes van hoge belasting wil ik voorkomen dat \u00e9\u00e9n enkele stream de CPU of de socket in beslag neemt. Ik gebruik <strong>sendfile_max_chunk<\/strong>, zodat NGINX de kernel na een bepaald aantal bytes teruggeeft en ruimte laat voor andere verbindingen. Voor bandbreedtebeheer helpen <em>limit_rate<\/em> en <em>limit_rate_after<\/em>, bijvoorbeeld om bulkdownloads te beperken, terwijl UI-elementen vlot blijven werken. Met <em>uitvoer uitstellen<\/em> Ik stel in vanaf welke antwoordgrootte NGINX begint met verzenden \u2013 in combinatie met tcp_nopush zorg ik zo voor nette pakketafbrekingen. Daarnaast let ik op <em>lingering_close<\/em>, zodat resterende pakketten netjes kunnen worden verzonden en de socket niet abrupt wordt be\u00ebindigd.<\/p>\n\n<h2>Bestandssystemen, readahead en opslagpaden<\/h2>\n\n<p>Omdat <strong>sendfile<\/strong> Bij het gebruik van paginacaches speelt het onderliggende bestandssysteem een grote rol. Ik controleer de readahead-waarden en stel ze zo in dat sequenti\u00eble leesbewerkingen van grote bestanden niet vastlopen, zonder dat dit ten koste gaat van kleinere bestanden. Op <em>ext4<\/em> of <em>xfs<\/em> Ik kijk hoe goed prefetching en de I\/O-scheduler aansluiten bij mijn doorvoerpatroon. Op netwerkbestandssystemen (NFS\/SMB) test ik rsize\/wsize, caching en latenties grondig, omdat zelfs kleine afwijkingen het zero-copy-voordeel tenietdoen. Mijn regel blijft: eerst lokale paden maximaal benutten, daarna externe stacks voorzichtig aanpassen \u2013 en meetwaarden altijd boven mijn intu\u00eftie stellen.<\/p>\n\n<h2>De netwerkstack en NIC-offloading pragmatisch op elkaar afstemmen<\/h2>\n\n<p>Voor een groot aantal verbindingen vertrouw ik op de automatische bufferanpassing van moderne stacks, maar pas indien nodig de verzend- en ontvangstbuffers aan. NIC-offloads zoals TSO, GSO en GRO verlagen de CPU-belasting merkbaar; bij metingen ga ik echter voorzichtig te werk, omdat pakketcaptures door offloading vertekend kunnen lijken (ogenschijnlijk weinig, maar zeer grote segmenten). Daarom breng ik <em>pcap<\/em>\u2011Traces met statistieken uit NGINX en de kernel, om de werkelijke bandbreedte te onderscheiden van offload-artefacten. Bij pieken in de latentie onderbreek ik de tests kort door de offloads uit te schakelen, documenteer ik het verschil en beslis ik vervolgens wat bij continu gebruik meer voordeel oplevert.<\/p>\n\n<h2>Configuratiepatronen per locatie: gericht in- en uitschakelen<\/h2>\n\n<p>Ik houd de mogelijkheid open om, <strong>sendfile<\/strong> afhankelijk van het pad of het bestandstype te overschrijven. Voor statische mappen blijft het ingeschakeld; voor streaming- of dynamische paden schakel ik het selectief uit wanneer buffers of filters (bijv. compressie) voorrang hebben. Een kort voorbeeld:<\/p>\n\n<pre><code>server {\n    listen 80;\n    server_name static.example.com;\n    root \/var\/www\/static;\n\n # Statische bestanden: Zero-Copy\n    location \/assets\/ {\n sendfile on;\n tcp_nopush on;\n        tcp_nodelay on;\n expires 7d;\n    }\n\n # Dynamisch of streaming: flexibiliteit boven Zero-Copy\n    location \/api\/ {\n sendfile off;\n proxy_pass http:\/\/app_upstream;\n    }\n}\n<\/code><\/pre>\n\n<p>Door deze scheiding voorkom ik dat ik aan de ene kant voordelen misloop, alleen maar omdat een ander traject specifieke eisen stelt.<\/p>\n\n<h2>Bereik, segmenten en grote catalogi<\/h2>\n\n<p>Bij grote objecten speelt <strong>Bereik<\/strong>-Verzoeken spelen hun sterke punten uit: de client laadt alleen de benodigde delen, en de verbindingen blijven stabiel. In inhoudscatalogi met zeer grote bestanden segmenteer ik de overdrachten graag op logische wijze \u2013 de serverbelasting wordt gelijkmatiger verdeeld en fouten, zoals afbrekingen, kosten minder tijd. In caching-scenario\u2019s voorkom ik \u201eThundering Herds\u201c door antwoorden op een zinvolle manier in de cache op te slaan, maar kleine chunks en restgegevens niet kunstmatig vast te houden. De interactie met tcp_nopush blijft daarbij cruciaal: ik houd de beginsegmenten groot, maar laat het einde niet wachten.<\/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>Meet- en teststrategie: effecten op betrouwbare wijze aantonen<\/h2>\n\n<p>Ik onderbouw optimalisaties met reproduceerbare tests. Aan de serverzijde houd ik de CPU-profielen in de gaten, <em>1TP4Vraag_tijd<\/em>, <em>$bytes_verzonden<\/em>, actieve verbindingen en contextwisselingen. Op het netwerk meet ik segmentgroottes, hertransmissies en RTT-verdeling; ik breng packet-captures in verband met socketstatistieken om rekening te houden met offload-effecten. Aan de clientzijde vergelijk ik TTFB, First Contentful Paint en downloadtijden bij realistische RTT\u2019s en bandbreedtes. Ik varieer de MTU, Keep-Alive-instellingen en bestandsgroottes, zodat ik niet alleen \u2018best-case\u2019-curves zie. Uiteindelijk beslis ik op basis van harde cijfers of sendfile\/tcp_nopush in de betreffende workload de gewenste stabiliteit en effici\u00ebntie bieden \u2013 en pas ik de instellingen nauwkeurig aan totdat dat het geval is.<\/p>\n\n<h2>HTTP-details die het verschil maken: Range en streaming<\/h2>\n\n<p>Ik gebruik <strong>Bereik<\/strong>-Verzoeken bij grote bestanden, zodat clients alleen de benodigde delen opnieuw laden en de verbindingen stabiel blijven. Met name bij het vooruitspoelen van video\u2019s en het hervatten van updates helpt een goede ondersteuning van byteranges om de doorvoersnelheid op een zinvolle manier te verdelen; achtergrondinformatie is te vinden op de pagina over <a href=\"https:\/\/webhosting.de\/nl\/http-bereik-aanvragen-media-en-download-hosting-prestaties-byte\/\">HTTP-Range-verzoeken<\/a>. Voor doorlopende antwoorden met een steeds grotere body test ik streamingstrategie\u00ebn en zorg ik ervoor dat buffers niet onbedoeld te lang worden vastgehouden. Daarbij houd ik rekening met caches en stel ik zinvolle headers in, zodat proxyservers en browsers correct reageren. Ik houd rekening met de interactie met tcp_nopush, omdat pakketgroottes en de timing van de flush directe invloed hebben op de waargenomen snelheid.<\/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 samengevat<\/h2>\n\n<p>Met <strong>sendfile<\/strong> Ik stuur bestanden effici\u00ebnt rechtstreeks door naar de kernel, en met `tcp_nopush` zorg ik ervoor dat de pakketten op een zinvolle manier worden gevuld voordat ze de verbinding belasten. Beide richtlijnen vullen elkaar aan, terwijl `tcp_nodelay` de laatste resterende byte zonder vertraging verzendt. Ik test het effect onder real-traffic, let op het opslagpad, de MTU, keep-alive en compressie, en voer consequent metingen uit. Voor WordPress- en CDN-achtige workloads wordt het voordeel bijzonder snel duidelijk, omdat veel verzoeken betrekking hebben op statische assets. Wie de instellingen doelgericht toepast, haalt meer doorvoer per kern, verlaagt de overhead en cre\u00ebert reserves voor echte groeipieken.<\/p>","protected":false},"excerpt":{"rendered":"<p>Praktische handleiding voor de configuratie van NGINX sendfile en tcp_nopush voor maximale prestaties bij het leveren van statische bestanden en grote 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":"119","_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\/nl\/wp-json\/wp\/v2\/posts\/20906","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=20906"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20906\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/20899"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=20906"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=20906"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=20906"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}