{"id":20714,"date":"2026-08-16T18:19:23","date_gmt":"2026-08-16T16:19:23","guid":{"rendered":"https:\/\/webhosting.de\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/"},"modified":"2026-08-16T18:19:23","modified_gmt":"2026-08-16T16:19:23","slug":"nginx-werkprocessen-optimaal-configureren-voor-een-prestatieverbetering","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/","title":{"rendered":"NGINX-werkprocessen optimaal configureren voor maximale prestaties"},"content":{"rendered":"<p>I configureren <strong>NGINX-worker<\/strong> zodat worker_processes, worker_connections en worker_rlimit_nofile precies op elkaar zijn afgestemd en Epoll in de event-loop werkt. Daardoor gebruik ik <strong>CPU-kernen<\/strong> Zorg voor effici\u00ebntie, maak het mogelijk om het aantal gelijktijdige verbindingen op een voorspelbare manier te schalen en houd de latentie laag tijdens piekbelastingen.<\/p>\n\n<h2>Centrale punten<\/h2>\n<p>De volgende kernpunten bieden je direct houvast voor een robuuste NGINX-worker-configuratie.<\/p>\n<ul>\n  <li><strong>werker_processen<\/strong> koppelen aan het aantal logische kernen, bij voorkeur met \u201eauto\u201c.<\/li>\n  <li><strong>werker_verbindingen<\/strong> zo instellen dat werkelijke pieken ruimschoots worden opgevangen.<\/li>\n  <li><strong>rlimit_nofile<\/strong> en de OS-limieten aanpassen aan de verbindingscapaciteit.<\/li>\n  <li><strong>epoll<\/strong> en multi_accept inschakelen om de event-loop effici\u00ebnt te benutten.<\/li>\n  <li><strong>Belastingstesten<\/strong> doorgaan en in kleine stapjes nauwkeurig bijstellen.<\/li>\n<\/ul>\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-optimierung-serverraum-5961.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NGINX-architectuur: inzicht in master en worker<\/h2>\n<p>Ik maak een onderscheid tussen de taken van <strong>Master<\/strong> en de workers: de master laadt configuraties, opent sockets en start processen, terwijl de workers in de event-loop verzoeken verwerken. Elke worker draait zelfstandig, reageert op gebeurtenissen en kan duizenden verbindingen beheren zonder blokkades te veroorzaken. Dit model komt goed tot zijn recht als ik CPU-kernen op de juiste manier inzet en de event-loop via epoll optimaal aanstuur. Ik houd er daarbij rekening mee dat elke extra proxy-hop verbindingsbronnen in beslag neemt, wat tot uiting komt in de limieten. Wie de rollen begrijpt, neemt bewuste beslissingen over <strong>Bronnen<\/strong> en voorkomt knelpunten in een vroeg stadium.<\/p>\n\n<h2>De drie belangrijkste richtlijnen op de juiste manier met elkaar verbinden<\/h2>\n<p>Ik beschouw <strong>werker_processen<\/strong>, worker_connections en worker_rlimit_nofile nooit afzonderlijk, maar als \u00e9\u00e9n geheel. Het totale aantal mogelijke verbindingen is het resultaat van het aantal workers vermenigvuldigd met het aantal verbindingen per worker; daaruit leid ik de limieten voor bestandsdescriptoren af. Als deze instellingen niet op elkaar zijn afgestemd, krijg ik te maken met \u201etoo many open files\u201c of harde time-outs. Voor hoge belasting heb ik een goed afgestemde keten nodig: voldoende processen, ruime verbindingen, netjes verhoogde rlimit_nofile en passende OS-parameters. Zo voorkom ik dat een te kleine <strong>Beperk<\/strong> de totale capaciteit is beperkt.<\/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_worker_meeting_3021.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>worker_processes: het aantal zorgvuldig kiezen<\/h2>\n<p>Ik stel <strong>werker_processen<\/strong> meestal op \u201eauto\u201c, zodat NGINX het aantal logische CPU-kernen herkent en elke kern kan benutten. E\u00e9n worker per kern voorkomt onnodige contextwisselingen en verdeelt de belasting gelijkmatig, waardoor de responstijd voorspelbaar blijft. Op machines met zeer veel kernen test ik bewust ook lagere aantallen workers om cache-hits en kernbezetting te vergelijken. Als uit de statistieken blijkt dat kernen overbelast raken of dat het aantal TLB-misses toeneemt, pas ik het aantal workers stapsgewijs aan. Eerst meten, dan aanpassen \u2013 zo zorg ik voor betrouwbare <strong>Resultaten<\/strong>.<\/p>\n\n<h2>worker_connections: het aantal verbindingen op een planbare manier verhogen<\/h2>\n<p>Ik kies voor de <strong>werker_verbindingen<\/strong> afhankelijk van het doelverkeer en de protocolmix, vaak beginnend bij 2048 of 4096. Voor drukbezochte API\u2019s overweeg ik 8192, mits de limieten van het besturingssysteem en het RAM-geheugen dit toelaten. Elke verhoging toets ik met belastingstests, omdat open verbindingen geheugen bezetten en het upstream-gedrag be\u00efnvloeden. Als SSL-handshakes of grote uploads de boventoon voeren, richt ik me eerder op CPU- en I\/O-profielen, en niet alleen op de kale verbindingsaantallen. Zo zorg ik ervoor dat het per worker gedefinieerde <strong>Capaciteit<\/strong> ook in de praktijk bruikbaar blijft.<\/p>\n\n<h2>worker_rlimit_nofile en OS-limieten synchroniseren<\/h2>\n<p>Ik zorg ervoor dat <strong>rlimit_nofile<\/strong> ten minste de theoretische totale capaciteit dekt en vaak met een reserve wordt geconfigureerd. Voor reverse-proxy-scenario\u2019s houd ik per clientverbinding rekening met een tweede descriptor voor de upstream. Daarom stel ik rlimit_nofile graag in op het dubbele van het verwachte aantal gelijktijdige verbindingen. De kernel- en gebruikerslimieten (ulimit -n, fs.file-max) verhoog ik zodanig dat NGINX de waarden daadwerkelijk kan benutten. Als er in het foutenlogboek meldingen over open bestanden verschijnen, verhoog ik de limieten onmiddellijk en houd ik de <strong>Latency<\/strong> onder belasting opnieuw.<\/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-5123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Evenementenblok: epoll en multi_accept effectief inzetten<\/h2>\n<p>Ik activeer in het evenementenblok <strong>epoll<\/strong> en stel multi_accept in op \u201eon\u201c, zodat workers wachtende verbindingen in \u00e9\u00e9n keer accepteren. Epoll vermindert de overhead bij veel gelijktijdige sockets en sluit goed aan bij het niet-blokkerende ontwerp van NGINX. Deze instellingen lonen zich bij pieken in het verkeer, omdat ik de acceptatiefase versnel en sneller bij de daadwerkelijke verwerking kom. Voor Linux is dit mijn standaardinstelling, die ik alleen in zeldzame, speciale gevallen aanpas. Wie zich hier verder in wil verdiepen, vergelijkt het event-loop-model met <a href=\"https:\/\/webhosting.de\/nl\/threadpool-webserver-apache-nginx-litespeed-optimalisatie-configuratie\/\">Threadpool versus event-loop<\/a> en trekt daaruit de conclusie dat <strong>conclusies<\/strong> voor de eigen omgeving.<\/p>\n\n<h2>CPU-affiniteit: workers aan cores koppelen<\/h2>\n<p>Ik stel <strong>worker_cpu_affinity<\/strong> Ik pas dit doelgericht toe wanneer workloads constant en CPU-gebonden zijn. Ik verdeel het toewijzingsschema via bitmaskers om contextwisselingen te vermijden en cache-localiteit te bevorderen. Bij vier kernen wijs ik de maskers zo toe dat elke worker een eigen kern krijgt. Vervolgens controleer ik de cache-miss-percentages, mediane latenties en 99e percentielen om het effect duidelijk te zien. Meer uitleg over affiniteit en NUMA vind je beknopt op <a href=\"https:\/\/webhosting.de\/nl\/serverproces-affiniteit-numa-bewustzijn-hosting-ressourcentuning\/\">CPU-affiniteit in de praktijk<\/a>, wat bij het verfijnen van <strong>Werknemer<\/strong>-Lay-outs helpt.<\/p>\n\n<h2>Capaciteit plannen: headroom en belastingstests<\/h2>\n<p>Bij verbindingen plan ik een <strong>Buffer<\/strong> die duidelijk boven de waargenomen pieken ligt, zodat kortstondige pieken niet direct de limieten overschrijden. Als ik de piekbelasting als uitgangspunt verdubbel, heb ik in veel scenario\u2019s een ruime marge. Bij sterk fluctuerend verkeer vergroot ik de buffer verder totdat de 99e percentielen soepel verlopen. Vervolgens controleer ik knelpunten met tools zoals wrk of k6, houd ik foutpercentages in de gaten en bekijk ik de status van open verbindingen. Pas als de statistieken consistent zijn, verhoog of verlaag ik gericht afzonderlijke <strong>Waarden<\/strong>.<\/p>\n\n<h2>Configuratie en rekenvoorbeelden<\/h2>\n<p>Ik bereken de verbindingscapaciteit door het aantal workers te vermenigvuldigen met het aantal verbindingen per worker en stel op basis daarvan de limieten iets hoger in. Bij vier CPU-kernen met de instelling \u2018auto\u2019 en 4096 verbindingen per worker kom ik uit op 16384 gelijktijdige verbindingen. In proxyscenario\u2019s stel ik rlimit_nofile liever in op 32.768 of hoger, zodat upstream-sockets hierin worden meegenomen. Voor kleine machines met twee kernen volstaan vaak 2048 verbindingen per worker, mits het aandeel van uploads en TLS gematigd blijft. De volgende tabel helpt bij het indelen van de <strong>Startwaarden<\/strong>:<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>CPU-kernen<\/th>\n      <th>werker_processen<\/th>\n      <th>worker_connections (Start)<\/th>\n      <th>Min. rlimit_nofile (richtwaarde)<\/th>\n      <th>Tip<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>2<\/td>\n      <td>auto (\u22482)<\/td>\n      <td>2048<\/td>\n      <td>\u2265 4096<\/td>\n      <td><strong>Reserve<\/strong> inplannen voor TLS\/proxy<\/td>\n    <\/tr>\n    <tr>\n      <td>4<\/td>\n      <td>auto (\u22484)<\/td>\n      <td>4096<\/td>\n      <td>\u2265 16384<\/td>\n      <td>Bij proxy's is de factor vaak 2 bij FD's<\/td>\n    <\/tr>\n    <tr>\n      <td>8<\/td>\n      <td>auto (\u22488)<\/td>\n      <td>4096-8192<\/td>\n      <td>\u2265 32768<\/td>\n      <td><strong>Belastingstest<\/strong> besluit over verhoging<\/td>\n    <\/tr>\n    <tr>\n      <td>16+<\/td>\n      <td>auto, eventueel minder<\/td>\n      <td>8192+<\/td>\n      <td>\u2265 65535<\/td>\n      <td>Met gevoel en terughoudendheid testen<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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_opt_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NGINX-workers en upstreams: scenario\u2019s op de juiste manier wegen<\/h2>\n<p>Ik maak onderscheid tussen statische levering, reverse-proxy-werking en API-gateway-belasting, omdat ze de <strong>Werknemer<\/strong>-configuratie stellen verschillende eisen. Statische inhoud verbruikt minder bronnen, terwijl TLS, compressie en upstream-verbindingen meer druk uitoefenen op de CPU en FD\u2019s. Hoe groter de SSL-sleutels en hoe meer handshakes, hoe meer voordeel er te behalen valt met de instelling \u201e\u00e9\u00e9n worker per kern\u201c. Grote uploads verschuiven het profiel naar I\/O, waardoor ik meer aandacht besteed aan rlimit_nofile en netwerkbuffers. Bij merkbare wachttijden bij het accepteren of bij backend-antwoorden helpt het overzicht mij om <a href=\"https:\/\/webhosting.de\/nl\/webserver-wachtrij-latentie-verzoekafhandeling-serverwachtrij\/\">Wachtrijen en latentie<\/a>, om knelpunten <strong>gericht<\/strong> op te lossen.<\/p>\n\n<h2>Workflow in de praktijk: stap voor stap naar een snellere server<\/h2>\n<p>Ik begin met een inventarisatie van alle relevante <strong>Waarden<\/strong> In het bestand nginx.conf controleer ik het aantal CPU-kernen, ulimit en de kernelparameters. Vervolgens stel ik worker_processes in op auto, stel ik worker_connections bijvoorbeeld in op 4096 en verhoog ik rlimit_nofile ruimschoots. In het Events-blok activeer ik epoll en multi_accept en controleer ik de logbestanden met een reload. Vervolgens voer ik belastingstests uit onder reproduceerbare omstandigheden, waarbij ik responstijden, foutpercentages en open verbindingen observeer. Bij de fijnafstemming wijzig ik altijd slechts \u00e9\u00e9n variabele, documenteer ik elke stap en controleer ik de effecten in de <strong>Metriek<\/strong>.<\/p>\n\n<h2>Hostingomgeving: bronnen, kernel, netwerk<\/h2>\n<p>Ik zorg ervoor dat er voldoende is <strong>CPU<\/strong>-Kernen, voldoende RAM, snelle SSD\u2019s of NVMe en een recente Linux-kernel. Alleen zo werken epoll, moderne TCP-stacks en zinvolle offload-functies betrouwbaar. Netwerkparameters zoals somaxconn en tcp_max_syn_backlog pas ik aan het beoogde aantal verbindingen aan, om de wachtrijen voor inkomend verkeer kort te houden. Een provider met robuuste I\/O-prestaties en vrij toegankelijke systeemconfiguratie loont zich hiervoor duidelijk. Uit vergelijkingen blijkt dat diensten met constante <strong>Bronnen<\/strong> De mogelijkheden van NGINX aanzienlijk vergroten.<\/p>\n\n<h2>Keepalive-strategie: client- en upstream-verbindingen<\/h2>\n<p>Ik gebruik Keepalive bewust als middel om de capaciteit en latentie te be\u00efnvloeden. Aan de clientzijde gebruik ik <strong>keepalive_timeout<\/strong> niet te hoog, zodat inactieve sockets niet onnodig <em>werker_verbindingen<\/em> blokkeren. Waarden tussen 10 en 30 s bieden mij vaak een goed compromis tussen hergebruik en het vastleggen van middelen. Met <strong>keepalive_requests<\/strong> Ik beperk het aantal verzoeken per verbinding om langlopende verbindingen af te kappen en geheugendruk te voorkomen. Aan de upstream-zijde (reverse-proxy) onderhoud ik permanente verbindingen met <strong>keepalive<\/strong> in het upstream-blok, zodat handshakes en TCP-configuratie overbodig worden. Daarbij schaal ik het aantal per backend conservatief op basis van de backend-capaciteit (<em>max_conns<\/em>), anders maak ik zelf wachtrijen aan bij de upstream. Belangrijk: elke keepalive-socket telt als een open verbinding en heeft FD\u2019s nodig; daar houd ik rekening mee in <em>rlimit_nofile<\/em> en mijn planning voor de headroom.<\/p>\n\n<h2>Lijstoptimalisatie: reuseport, backlog en acceptatiestrategie<\/h2>\n<p>Ik verdeel de opnamebelasting gelijkmatig door <strong>SO_REUSEPORT<\/strong> activeer (listen \u2026 reuseport). Elke worker beschikt daarmee over een eigen accept-queue, wat \u201ethundering herds\u201c vermindert en hotspots voorkomt. In combinatie met <strong>multi_accept<\/strong> versnel ik de acceptatiefase merkbaar. De lijsten-<strong>achterstand<\/strong> (listen \u2026 backlog=) en de bijbehorende kernelinstellingen (somaxconn, tcp_max_syn_backlog) stel ik ruim in, zodat pieken niet verloren gaan bij de socket-ingang. De optie <strong>uitgesteld<\/strong> stelt Accept uit totdat de gegevens beschikbaar zijn \u2013 bij veel kortstondige verzoeken kan dat helpen; anders vergelijk ik het in tests. Of ik <strong>accept_mutex<\/strong> Wat ik nodig heb, bepaal ik aan de hand van de benchmark: met reuseport is het meestal overbodig; zonder reuseport kan het de eerlijkheid verbeteren, maar het vergt wel co\u00f6rdinatie. Hier neem ik een besluit op basis van gegevens, nooit op gevoel.<\/p>\n\n<h2>Time-outs en wachtrijen stabiel instellen<\/h2>\n<p>Ik stel <strong>Time-outs<\/strong> zodat trage clients de workers niet verstoppen: <em>client_header_timeout<\/em> en <em>cli\u00ebnt_lichaam_timeout<\/em> Ik houd het kort genoeg om vertragingen te voorkomen, maar ruim genoeg voor echte gebruikers. <em>send_timeout<\/em> voorkomt dat antwoorden naar de client worden geblokkeerd. In de proxy-context definieer ik <em>proxy_connect_timeout<\/em>, <em>proxy_read_timeout<\/em> en <em>proxy_send_timeout<\/em> strikt, zodat de backends die daarmee samenhangen de frontend niet vertragen. Bij backends met beperkte parallelliteit gebruik ik <strong>wachtrij<\/strong> in het upstream-blok met een time-out, om pieken op te vangen en op een gecontroleerde manier een 503-fout te signaleren, in plaats van alle workers aan wachtende upstream-sockets te koppelen. Daarnaast zorg ik voor stabiliteit door <strong>limit_req<\/strong> (Burst\/Delay) en <strong>limit_conn<\/strong> gevoelige paden, zodat individuele clients of bots niet onevenredig veel bronnen verbruiken.<\/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_worker_performance_8392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Buffering, sendfile en AIO: bewust kiezen voor I\/O-methoden<\/h2>\n<p>Ik stel <strong>sendfile<\/strong> voor statische bestanden en combineer dit met <em>tcp_nopush<\/em>\/<em>tcp_nodelay<\/em> afhankelijk van de werklast, om pakketten effici\u00ebnt te bundelen of interactieve vertragingen te verminderen. Voor grote bestanden gebruik ik <strong>directio<\/strong> vanaf een bepaalde drempelwaarde, zodat cache-pollution wordt voorkomen en de paginacache niet wordt verdrongen. In de proxy-modus bepaal ik of <strong>proxy_buffering<\/strong> helpt (snelle overdracht naar de client, ontkoppeld lezen van de upstream) of dat ik bij streamingbelastingen liever <em>proxy_request_buffering<\/em> verklein, om uploads vroegtijdig te starten. De grootte van <em>proxy_buffers<\/em>, <em>proxy_buffer_size<\/em> en <em>large_client_header_buffers<\/em> Ik stuur dit bewust aan, zodat het geheugengebruik per verbinding niet explosief stijgt. Om de CPU te ontzien bij het openen van bestanden, overweeg ik <strong>aio<\/strong> (native of threads), maar test dit grondig, omdat de kenmerken van de event-loop en de I\/O elkaar be\u00efnvloeden.<\/p>\n\n<h2>HTTP\/2\/HTTP\/3 en TLS: gevolgen voor de capaciteit van workers<\/h2>\n<p>Ik houd er rekening mee dat <strong>HTTP\/2<\/strong> en <strong>HTTP\/3<\/strong> De verbindingsdynamiek wijzigen: veel verzoeken worden uitgevoerd als <em>Streams<\/em> via een klein aantal TCP- of QUIC-verbindingen. Dit vermindert het aantal verbindingen, maar verhoogt het CPU- en geheugenverbruik per verbinding (multiplexing, headercompressie, TLS\/QUIC). Mijn <em>werker_verbindingen<\/em> Ik interpreteer dit daarom niet zomaar als \u201eevenveel verzoeken\u201c. Ik merk op dat <em>gelijktijdige streams<\/em> per verbinding en pas <em>keepalive_timeout<\/em> en indien van toepassing. <em>http2_max_concurrent_streams<\/em> . Aan de TLS-kant profiteer ik van sessieherstel (tickets\/cache) en OCSP-stapling; zo bespaar ik dure handshakes en houd ik de latentie laag. De keerzijde: langere keepalives leggen beslag op FD\u2019s en RAM \u2013 dus plan ik <em>rlimit_nofile<\/em> en geheugencontingenten met realistische reserves. Voor CPU-intensieve versleutelingsalgoritmen loont het de moeite om affiniteit en moderne cryptografische versnelling te testen.<\/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-optimaler-setup-9182.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring: status, logbestanden en statistieken<\/h2>\n<p>Ik zorg voor transparantie met een gestroomlijnde <strong>Status<\/strong>-Endpoint (bijv. stub_status) om actieve verbindingen, Reading\/Writing\/Waiting en geaccepteerde verzoeken te bekijken. In de logbestanden houd ik de ruis beperkt: een compacte <em>log_format<\/em> met tijd, status, upstream-tijden en bytes is voldoende voor de meeste analyses. Bij een zeer hoge QPS schakel ik het toegangslogboek selectief uit (op basis van locatie) of sla ik logbestanden asynchroon op, zodat de I\/O geen vertraging veroorzaakt. Het foutenlogboek stel ik in op <em>waarschuw<\/em> of <em>fout<\/em> en schakel alleen voor gerichte analyses tijdelijk over naar <em>debug<\/em>. Ik breng voortdurend de latenties (mediaan\/95e\/99e percentiel), open verbindingen, backend-foutpercentages en CPU-belasting per worker met elkaar in verband \u2013 op basis daarvan leid ik aanpassingen van de drie belangrijkste richtlijnen af en signaleer ik in een vroeg stadium verzadigingseffecten.<\/p>\n\n<h2>Containers en virtuele omgevingen: limieten netjes doorgeven<\/h2>\n<p>Ik controleer in containers de <strong>cgroup<\/strong>-Stel limieten in voor CPU, RAM en PID's en stem deze af op de NGINX-instellingen. <em>ulimit -n<\/em> moet binnen de container hoog genoeg zijn, anders hebben mijn aanpassingen aan rlimit_nofile geen zin. Bij CPU-quota\u2019s (bijv. 2 vCPU\u2019s) stel ik <em>werker_processen<\/em> Dienovereenkomstig, zodat de planning niet kunstmatig wordt versneld. Dicht bij het netwerk profiteer ik in \u201ehost\u201c-netwerkmodi van een lagere overhead-latentie, terwijl overlays extra hops betekenen. Op Multi-NUMA-hosts let ik op affiniteit en geheugensockets, zodat workers niet over verschillende nodes heen werken. Hetzelfde geldt voor IRQ- en RPS\/XPS-affiniteit: als de paden van de NIC via de IRQ naar de worker-kern kloppen, nemen de latentiepieken meetbaar af.<\/p>\n\n<h2>Verbindingslevenscyclus: tijdelijke poorten, TIME_WAIT en reserves<\/h2>\n<p>Ik plan voldoende <strong>tijdelijke poorten<\/strong> (ip_local_port_range), wanneer NGINX als actieve client naar upstreams fungeert. Bij een zeer hoge verbindingsdoorvoer voorkom ik overmatige poortfluctuatie met upstream-keepalive, waardoor TIME_WAIT-stacks kleiner worden. Ik maak slechts voorzichtig gebruik van kernel-toggles voor \u201eReuse\u201c; moderne stacks optimaliseren veel zaken al intern. Het is stabieler om de levensduur van verbindingen te regelen via zinvolle keepalive- en timeout-waarden en <em>hergebruik<\/em> om te zorgen voor een eerlijke verdeling. Bij de capaciteitsberekening houd ik naast de clients altijd rekening met de upstream-kant \u2013 vaak zijn daar de FD\u2019s de daadwerkelijke beperkende factor, niet de frontdoor.<\/p>\n\n<h2>Soepele herlaadbeurten en implementaties zonder onderbrekingen<\/h2>\n<p>Ik gebruik het master\/worker-model voor <strong>soepele herlaadbeurten<\/strong>: De master laadt nieuwe configuraties; oude workers worden afgebroken, terwijl nieuwe het naadloos overnemen. Met <em>worker_shutdown_timeout<\/em> geef ik requests de tijd om netjes af te lopen, zonder resources te blokkeren. Zero-downtime-implementaties op de upstream koppel ik aan health checks en <em>proxy_next_upstream<\/em>-Regels om te voorkomen dat afzonderlijke defecte backends de algemene latentie doen stijgen. Bij configuratiewijzigingen pas ik altijd slechts \u00e9\u00e9n instelling aan en controleer ik de effecten in de logbestanden en statistieken \u2013 zo voorkom ik fouten door verwarring en zorg ik ervoor dat de prestaties reproduceerbaar blijven.<\/p>\n\n<h2>Beknopte samenvatting<\/h2>\n<p>Ik koppel <strong>werker_processen<\/strong> Stel het aantal kernen in (bij voorkeur automatisch), pas `worker_connections` aan op basis van de piekbelasting en verhoog `rlimit_nofile` en de OS-limieten ruimschoots. In het `events`-blok gebruik ik `epoll` en `multi_accept`, controleer ik alles met reproduceerbare belastingstests en pas ik vervolgens in kleine stapjes bij. Voor proxy-workloads houd ik rekening met extra descriptoren en test ik de CPU-affiniteit wanneer de workloads constant zijn. Een goed geconfigureerde stack met de juiste kernel, snelle I\/O en zinvolle netwerkparameters maakt het verschil. Zo zorg ik ervoor dat <strong>NGINX<\/strong> betrouwbaar in het prestatiebereik dat veeleisende websites en API's nodig hebben.<\/p>","protected":false},"excerpt":{"rendered":"<p>Ontdek hoe je NGINX-werkprocessen op de juiste manier instelt en de prestaties van de webserver aanzienlijk verbetert door middel van gerichte NGINX-tuning.<\/p>","protected":false},"author":1,"featured_media":20707,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20714","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":"128","_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 Worker","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":"20707","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20714","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=20714"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20714\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/20707"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=20714"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=20714"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=20714"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}