{"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":"optimal-konfiguration-af-nginx-arbejdsprocesser-ydeevneforbedring","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/","title":{"rendered":"Optimal konfiguration af NGINX-arbejdsprocesser for maksimal ydeevne"},"content":{"rendered":"<p>Jeg konfigurerer <strong>NGINX-arbejder<\/strong> s\u00e5ledes at worker_processes, worker_connections og worker_rlimit_nofile passer n\u00f8jagtigt sammen, og Epoll fungerer i event-loopen. Dermed bruger jeg <strong>CPU-kerner<\/strong> V\u00e6r effektiv, skal\u00e9r antallet af samtidige forbindelser p\u00e5 en planlagt m\u00e5de og hold latenstiderne lave ved spidsbelastninger.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<p>F\u00f8lgende centrale aspekter giver dig en hurtig oversigt over, hvordan du opretter en robust NGINX-worker-konfiguration.<\/p>\n<ul>\n  <li><strong>arbejdsprocesser<\/strong> koble det til antallet af logiske kerner, helst med \u201eauto\u201c.<\/li>\n  <li><strong>arbejdstager_forbindelser<\/strong> indstille den s\u00e5ledes, at reelle spidsbelastninger let kan d\u00e6kkes.<\/li>\n  <li><strong>rlimit_nofile<\/strong> og \u00f8ge OS-begr\u00e6nsningerne i overensstemmelse med forbindelsesm\u00e6ngden.<\/li>\n  <li><strong>epoll<\/strong> og aktivere multi_accept for at udnytte event-loopen effektivt.<\/li>\n  <li><strong>Belastningstest<\/strong> k\u00f8re og finjustere i sm\u00e5 trin.<\/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-arkitektur: S\u00e5dan forst\u00e5r du master- og worker-servere<\/h2>\n<p>Jeg adskiller opgaverne fra <strong>Mester<\/strong> og workerne er tydelige: Masteren indl\u00e6ser konfigurationer, \u00e5bner sockets og starter processer, mens workerne behandler anmodninger i event-loopen. Hver worker k\u00f8rer uafh\u00e6ngigt, reagerer p\u00e5 begivenheder og kan h\u00e5ndtere tusindvis af forbindelser uden at for\u00e5rsage blokeringer. Denne model fungerer optimalt, n\u00e5r jeg udnytter CPU-kernerne hensigtsm\u00e6ssigt og udnytter event-loopen optimalt via epoll. Jeg er opm\u00e6rksom p\u00e5, at hvert ekstra proxy-hop belaster forbindelsesressourcerne, hvilket afspejles i begr\u00e6nsningerne. Den, der forst\u00e5r rollerne, tr\u00e6ffer bevidste beslutninger om <strong>Ressourcer<\/strong> og forhindrer flaskehalse i god tid.<\/p>\n\n<h2>At kombinere de tre centrale retningslinjer p\u00e5 den rigtige m\u00e5de<\/h2>\n<p>Jeg overvejer <strong>arbejdsprocesser<\/strong>, worker_connections og worker_rlimit_nofile skal aldrig betragtes isoleret, men som en helhed. Det samlede antal mulige forbindelser beregnes ved at gange antallet af arbejdsprocesser med antallet af forbindelser pr. arbejdsproces; ud fra dette fastl\u00e6gger jeg gr\u00e6nserne for filbeskrivere. Hvis disse indstillinger ikke stemmer overens, st\u00f8der jeg p\u00e5 fejlen \u201etoo many open files\u201c eller oplever alvorlige timeouts. Ved h\u00f8j belastning har jeg brug for en harmonisk k\u00e6de: tilstr\u00e6kkeligt antal processer, gener\u00f8se forbindelser, en passende forh\u00f8jelse af rlimit_nofile og passende OS-parametre. P\u00e5 den m\u00e5de forhindrer jeg, at en for lille <strong>Gr\u00e6nse<\/strong> den samlede kapacitet er sat ud af drift.<\/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: V\u00e6lg et bestemt antal<\/h2>\n<p>Jeg s\u00e6tter <strong>arbejdsprocesser<\/strong> Som regel indstilles den til \u201eauto\u201c, s\u00e5 NGINX kan genkende antallet af logiske CPU-kerner og udnytte hver enkelt kerne. \u00c9n worker pr. kerne undg\u00e5r un\u00f8dvendige kontekstskift og fordeler belastningen j\u00e6vnt, hvilket g\u00f8r reaktionstiden forudsigelig. P\u00e5 maskiner med meget mange kerner tester jeg bevidst ogs\u00e5 lavere antal arbejdsprocesser for at sammenligne cache-hits og kerneudnyttelse. Hvis m\u00e5lingerne viser, at kernerne er overbelastede, eller at TLB-misses stiger, justerer jeg antallet af arbejdsprocesser trinvist. F\u00f8rst m\u00e5le, s\u00e5 \u00e6ndre \u2013 s\u00e5dan sikrer jeg p\u00e5lidelige <strong>Resultater<\/strong>.<\/p>\n\n<h2>worker_connections: For\u00f8gelse af forbindelser, der kan planl\u00e6gges<\/h2>\n<p>Jeg v\u00e6lger <strong>arbejdstager_forbindelser<\/strong> afh\u00e6ngigt af m\u00e5ltrafikken og protokolsammens\u00e6tningen, ofte med udgangspunkt i 2048 eller 4096. For API\u2019er med h\u00f8j trafik overvejer jeg 8192, forudsat at operativsystemets begr\u00e6nsninger og RAM-kapaciteten tillader det. Jeg tester hver forh\u00f8jelse med belastningstests, da \u00e5bne forbindelser binder hukommelse og p\u00e5virker upstream-adf\u00e6rd. Hvis SSL-handshakes eller store uploads dominerer, orienterer jeg mig snarere efter CPU- og I\/O-profiler end blot de rene forbindelsestal. P\u00e5 den m\u00e5de sikrer jeg, at den pr. worker definerede <strong>Kapacitet<\/strong> ogs\u00e5 forbliver anvendelig i praksis.<\/p>\n\n<h2>Synkronisering af worker_rlimit_nofile og OS-gr\u00e6nser<\/h2>\n<p>Jeg s\u00f8rger for, at <strong>rlimit_nofile<\/strong> d\u00e6kker mindst den beregnede samlede kapacitet og er ofte konfigureret med en reserve. I reverse-proxy-scenarier regner jeg med en ekstra deskriptor til upstream pr. klientforbindelse. Derfor indstiller jeg gerne rlimit_nofile til det dobbelte af det forventede antal samtidige forbindelser. Jeg h\u00e6ver kerne- og brugergr\u00e6nserne (ulimit -n, fs.file-max) s\u00e5 meget, at NGINX rent faktisk kan udnytte v\u00e6rdierne. Hvis der optr\u00e6der meddelelser om \u00e5bne filer i fejlloggen, h\u00e6ver jeg gr\u00e6nserne hurtigt og overv\u00e5ger <strong>Forsinkelse<\/strong> under belastning igen.<\/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>Begivenhedsblok: Effektiv anvendelse af epoll og multi_accept<\/h2>\n<p>Jeg aktiverer i begivenhedsblokken <strong>epoll<\/strong> og s\u00e6t multi_accept til \u201eon\u201c, s\u00e5 worker-processerne accepterer ventende forbindelser i \u00e9n omgang. Epoll reducerer overhead ved mange samtidige sockets og passer godt sammen med NGINX\u2019 ikke-blokerende design. Disse indstillinger betaler sig ved trafikspidser, fordi jeg fremskynder acceptfasen og hurtigere kommer videre til den egentlige behandling. For Linux er dette min standardindstilling, som jeg kun \u00e6ndrer i sj\u00e6ldne, specielle tilf\u00e6lde. Hvis du vil dykke dybere ned i emnet, kan du sammenligne event-loop-modellen med <a href=\"https:\/\/webhosting.de\/da\/threadpool-webserver-apache-nginx-litespeed-optimering-konfiguration\/\">Threadpool kontra event-loop<\/a> og drager heraf den konklusion, at <strong>konklusioner<\/strong> for ens eget milj\u00f8.<\/p>\n\n<h2>CPU-affinitet: Bind arbejdsprocesser til kerner<\/h2>\n<p>Jeg s\u00e6tter <strong>worker_cpu_affinity<\/strong> m\u00e5lrettet, n\u00e5r arbejdsbelastningerne er konstante og CPU-afh\u00e6ngige. Jeg fordeler tildelingsskemaet via bitmasker for at undg\u00e5 kontekstskift og fremme cache-lokalitet. Med fire kerner tildeler jeg maskerne s\u00e5ledes, at hver worker f\u00e5r sin egen kerne. Derefter kontrollerer jeg cache-miss-rater, median-latenser og 99-percentiler for tydeligt at kunne se effekten. Du finder en kortfattet forklaring p\u00e5 affinitet og NUMA p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/server-process-affinity-numa-awareness-hosting-ressourcentuning\/\">CPU-affinitet i praksis<\/a>, hvilket ved finjusteringen af <strong>Arbejder<\/strong>-Layouts hj\u00e6lper.<\/p>\n\n<h2>Kapacitetsplanl\u00e6gning: Headroom og belastningstests<\/h2>\n<p>N\u00e5r jeg opretter forbindelser, planl\u00e6gger jeg en <strong>Buffer<\/strong> et niveau, der ligger markant over de observerede spidsbelastninger, s\u00e5 kortvarige stigninger ikke straks overskrider gr\u00e6nserne. Hvis jeg fordobler spidsbelastningen som udgangspunkt, har jeg i mange scenarier et solidt spillerum. Ved st\u00e6rkt svingende trafik udvider jeg bufferen yderligere, indtil 99-percentilerne forl\u00f8ber problemfrit. Derefter tjekker jeg flaskehalse med v\u00e6rkt\u00f8jer som wrk eller k6, overv\u00e5ger fejlprocenterne og ser p\u00e5 \u00e5bne forbindelser i statusoversigten. F\u00f8rst n\u00e5r m\u00e5lingerne er konsistente, \u00f8ger eller s\u00e6nker jeg m\u00e5lrettet enkelte <strong>V\u00e6rdier<\/strong>.<\/p>\n\n<h2>Konfiguration og regneeksempler<\/h2>\n<p>Jeg beregner forbindelseskapaciteten ved at gange antallet af arbejdere med antallet af forbindelser pr. arbejdere og fasts\u00e6tter derefter de afledte gr\u00e6nser til et h\u00f8jere niveau. Med fire CPU-kerner, \u00bbauto\u00ab og 4096 forbindelser pr. arbejdere ender jeg teoretisk set p\u00e5 16384 samtidige forbindelser. I proxyscenarier indstiller jeg rlimit_nofile helst til 32.768 eller derover, s\u00e5 upstream-sockets er inkluderet. For sm\u00e5 maskiner med to kerner er 2048 forbindelser pr. worker ofte tilstr\u00e6kkeligt, forudsat at andelen af upload og TLS forbliver moderat. F\u00f8lgende tabel hj\u00e6lper med at indordne <strong>Startv\u00e6rdier<\/strong>:<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>CPU-kerner<\/th>\n      <th>arbejdsprocesser<\/th>\n      <th>worker_connections (Start)<\/th>\n      <th>Min. rlimit_nofile (vejledende v\u00e6rdi)<\/th>\n      <th>Hint<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>2<\/td>\n      <td>bil (\u22482)<\/td>\n      <td>2048<\/td>\n      <td>\u2265 4096<\/td>\n      <td><strong>Reserve<\/strong> Planl\u00e6gge for TLS\/proxy<\/td>\n    <\/tr>\n    <tr>\n      <td>4<\/td>\n      <td>bil (\u22484)<\/td>\n      <td>4096<\/td>\n      <td>\u2265 16 384<\/td>\n      <td>Ved proxy er der ofte en faktor 2 ved FD'er<\/td>\n    <\/tr>\n    <tr>\n      <td>8<\/td>\n      <td>bil (\u22488)<\/td>\n      <td>4096-8192<\/td>\n      <td>\u2265 32768<\/td>\n      <td><strong>Belastningstest<\/strong> tr\u00e6ffer beslutning om forh\u00f8jelse<\/td>\n    <\/tr>\n    <tr>\n      <td>16+<\/td>\n      <td>bil, eventuelt f\u00e6rre<\/td>\n      <td>8192+<\/td>\n      <td>\u2265 65535<\/td>\n      <td>Test med interesse og tilbageholdenhed<\/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-workere og upstreams: V\u00e6gtning af scenarier p\u00e5 den rigtige m\u00e5de<\/h2>\n<p>Jeg skelner mellem statisk levering, reverse-proxy-drift og API-gateway-belastning, fordi de <strong>Arbejder<\/strong>-konfigurationen stiller forskellige krav. Statisk indhold belaster f\u00e6rre ressourcer, mens TLS, komprimering og upstream-forbindelser belaster CPU og FD\u2019er i h\u00f8jere grad. Jo st\u00f8rre SSL-n\u00f8glerne er, og jo flere handshakes der er, desto st\u00f8rre fordel er der ved indstillingen \u201e\u00e9n worker pr. kerne\u201c. Store uploads flytter fokus over p\u00e5 I\/O, hvilket f\u00e5r mig til at kigge n\u00e6rmere p\u00e5 rlimit_nofile og netv\u00e6rksbuffere. Ved m\u00e6rkbare ventetider p\u00e5 modtagelse eller svar fra backend hj\u00e6lper det mig at f\u00e5 et overblik over <a href=\"https:\/\/webhosting.de\/da\/webserver-koing-latenstid-handtering-af-anmodninger-serverko\/\">K\u00f8er og ventetid<\/a>, for at undg\u00e5 flaskehalse <strong>m\u00e5lrettet<\/strong> l\u00f8se.<\/p>\n\n<h2>Arbejdsgang i praksis: Trin for trin til en hurtigere server<\/h2>\n<p>Jeg begynder med at kortl\u00e6gge den nuv\u00e6rende situation for alle relevante <strong>V\u00e6rdier<\/strong> I nginx.conf tjekker jeg CPU-kerner, ulimit og kerneparametre. Derefter indstiller jeg worker_processes til auto, s\u00e6tter f.eks. worker_connections til 4096 og \u00f8ger rlimit_nofile gener\u00f8st. I Events-blokken aktiverer jeg epoll samt multi_accept og kontrollerer logfilerne ved at genindl\u00e6se. Derefter f\u00f8lger belastningstests under reproducerbare betingelser, hvor jeg overv\u00e5ger responstider, fejlrater og \u00e5bne forbindelser. I finjusteringen \u00e6ndrer jeg altid kun \u00e9n variabel ad gangen, dokumenterer hvert trin og kontrollerer virkningerne i <strong>Metrikker<\/strong>.<\/p>\n\n<h2>Hostingmilj\u00f8: Ressourcer, kerne, netv\u00e6rk<\/h2>\n<p>Jeg s\u00f8rger for, at der er tilstr\u00e6kkeligt <strong>CPU<\/strong>-Kerner, tilstr\u00e6kkelig RAM, hurtige SSD\u2019er eller NVMe og en opdateret Linux-kerne. Kun p\u00e5 den m\u00e5de fungerer epoll, moderne TCP-stakke og nyttige offload-funktioner p\u00e5lideligt. Jeg tilpasser netv\u00e6rksparametre som somaxconn og tcp_max_syn_backlog til det forventede antal forbindelser for at holde modtagelsesk\u00f8erne korte. En udbyder med robust I\/O-ydeevne og frit tilg\u00e6ngelig systemkonfiguration betaler sig klart i denne sammenh\u00e6ng. Sammenligninger viser, at tjenester med konstante <strong>Ressourcer<\/strong> Udvid NGINX\u2019s fleksibilitet betydeligt.<\/p>\n\n<h2>Keepalive-strategi: Klient- og upstream-forbindelser<\/h2>\n<p>Jeg bruger bevidst Keepalive som et redskab til at styre kapacitet og latenstid. P\u00e5 klientsiden indstiller jeg <strong>keepalive_timeout<\/strong> ikke for h\u00f8jt, s\u00e5 inaktive sockets ikke un\u00f8digt <em>arbejdstager_forbindelser<\/em> blokere. V\u00e6rdier mellem 10 og 30 sekunder giver mig ofte et godt kompromis mellem genbrug og ressourceforbrug. Med <strong>keepalive_requests<\/strong> begr\u00e6nser jeg antallet af anmodninger pr. forbindelse for at afbryde langvarige forbindelser og undg\u00e5 belastning af hukommelsen. P\u00e5 upstream-siden (reverse-proxy) opretholder jeg vedvarende forbindelser med <strong>keepalive<\/strong> i upstream-blokken, s\u00e5 der ikke er behov for handshakes og TCP-ops\u00e6tning. Her skalerer jeg antallet pr. backend konservativt i forhold til backend-kapaciteten (<em>max_conns<\/em>), ellers opretter jeg selv k\u00f8er ved upstream. Vigtigt: Hver keepalive-socket t\u00e6ller som en \u00e5ben forbindelse og kr\u00e6ver FD\u2019er; det tager jeg h\u00f8jde for i <em>rlimit_nofile<\/em> og min planl\u00e6gning af headroom.<\/p>\n\n<h2>Listeoptimering: Reuseport, backlog og acceptstrategi<\/h2>\n<p>Jeg fordeler modtagelsesbyrden j\u00e6vnt ved at <strong>SO_REUSEPORT<\/strong> aktiver (listen \u2026 reuseport). Hver worker har dermed sin egen accept-k\u00f8, hvilket reducerer \u201ethundering herds\u201c og undg\u00e5r hotspots. I kombination med <strong>multi_accept<\/strong> fremskynder jeg modtagelsesfasen m\u00e6rkbart. Listen-<strong>Eftersl\u00e6b<\/strong> (listen \u2026 backlog=) og de tilsvarende indstillinger i kernen (somaxconn, tcp_max_syn_backlog) indstiller jeg gener\u00f8st, s\u00e5 spidsbelastninger ikke g\u00e5r tabt ved socket-indgangen. Indstillingen <strong>udskudt<\/strong> uds\u00e6tter Accept, indtil data foreligger \u2013 det kan v\u00e6re en hj\u00e6lp, hvis der er mange kortvarige anmodninger; ellers sammenligner jeg i testene. Om jeg <strong>accept_mutex<\/strong> Hvad jeg har brug for, afklarer jeg i benchmark-analysen: Med reuseport er det som regel un\u00f8dvendigt; uden reuseport kan det forbedre retf\u00e6rdigheden, men kr\u00e6ver koordinering. Her tr\u00e6ffer jeg beslutninger p\u00e5 baggrund af data, aldrig ud fra mavefornemmelse.<\/p>\n\n<h2>Indstil timeouts og k\u00f8er, s\u00e5 de fungerer stabilt<\/h2>\n<p>Jeg s\u00e6tter <strong>Timeouts<\/strong> s\u00e5ledes at langsomme klienter ikke overbelaster workerne: <em>client_header_timeout<\/em> og <em>client_body_timeout<\/em> Jeg holder det kort nok til at undg\u00e5 afbrydelser, men gener\u00f8st nok for virkelige brugere. <em>send_timeout<\/em> forhindrer, at svar til klienten bliver blokeret. I proxy-sammenh\u00e6ng definerer jeg <em>proxy_connect_timeout<\/em>, <em>proxy_read_timeout<\/em> og <em>proxy_send_timeout<\/em> strengt, s\u00e5 de ventende backends ikke lammer frontenden. Ved backends med begr\u00e6nset parallelitet bruger jeg <strong>k\u00f8<\/strong> i upstream-blokken med timeout for at afb\u00f8de spidsbelastninger og signalere 503 p\u00e5 en kontrolleret m\u00e5de, i stedet for at binde alle workere til ventende upstream-sockets. Derudover stabiliserer jeg med <strong>limit_req<\/strong> (Burst\/Delay) og <strong>limit_conn<\/strong> f\u00f8lsomme stier, s\u00e5 enkelte klienter eller bots ikke tr\u00e6kker uforholdsm\u00e6ssigt mange ressourcer.<\/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 og AIO: Bevidst valg af I\/O-metoder<\/h2>\n<p>Jeg s\u00e6tter <strong>sendfile<\/strong> til statiske filer og kombiner det med <em>tcp_nopush<\/em>\/<em>tcp_nodelay<\/em> afh\u00e6ngigt af arbejdsbyrden, for at samle pakker effektivt eller reducere interaktive forsinkelser. Til store filer bruger jeg <strong>Direktion<\/strong> fra en bestemt t\u00e6rskel, s\u00e5 der ikke opst\u00e5r cache-forurening, og sidecachen ikke fortr\u00e6nges. I proxy-tilstand beslutter jeg, om <strong>proxy_buffering<\/strong> hj\u00e6lper (hurtig overf\u00f8rsel til klienten, afkoblet upstream-afl\u00e6sning), eller om jeg ved streaming-belastninger hellere b\u00f8r <em>proxy_request_buffering<\/em> reducer for at igangs\u00e6tte uploads i god tid. St\u00f8rrelserne p\u00e5 <em>proxy_buffers<\/em>, <em>proxy_buffer_size<\/em> og <em>store_klient-header-buffere<\/em> Jeg styrer dette bevidst, s\u00e5 hukommelsesforbruget pr. forbindelse ikke eksploderer. For at sk\u00e5ne CPU\u2019en ved filadgang overvejer jeg <strong>aio<\/strong> (native eller tr\u00e5de), men test grundigt, da event-loop- og I\/O-egenskaberne p\u00e5virker hinanden.<\/p>\n\n<h2>HTTP\/2\/HTTP\/3 og TLS: Indvirkning p\u00e5 worker-kapaciteten<\/h2>\n<p>Jeg tager h\u00f8jde for, at <strong>HTTP\/2<\/strong> og <strong>HTTP\/3<\/strong> \u00c6ndre forbindelsesdynamikken: Mange anmodninger k\u00f8rer som <em>Streams<\/em> via f\u00e5 TCP- eller QUIC-forbindelser. Det reducerer antallet af forbindelser, men \u00f8ger CPU- og hukommelsesforbruget pr. forbindelse (multiplexing, header-komprimering, TLS\/QUIC). Min <em>arbejdstager_forbindelser<\/em> Derfor tolker jeg det ikke blindt som \u201elige mange anmodninger\u201c. Jeg observerer <em>samtidige str\u00f8mme<\/em> pr. forbindelse og passe <em>keepalive_timeout<\/em> og eventuelt. <em>http2_max_concurrent_streams<\/em> . P\u00e5 TLS-siden vinder jeg med session-resumption (billetter\/cache) og OCSP-stapling; p\u00e5 den m\u00e5de sparer jeg dyre handshakes og holder latenstiderne lave. Ulempen: L\u00e6ngere keepalives binder FD\u2019er og RAM \u2013 derfor planl\u00e6gger jeg <em>rlimit_nofile<\/em> og hukommelseskvoter med realistiske reserver. For CPU-kr\u00e6vende krypteringsalgoritmer er det v\u00e6rd at afpr\u00f8ve affinitet og moderne kryptografisk acceleration.<\/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>Overv\u00e5gning: Status, logfiler og m\u00e5linger<\/h2>\n<p>Jeg skaber gennemsigtighed med en str\u00f8mlinet <strong>Status<\/strong>-Endpoint (f.eks. stub_status) for at se aktive forbindelser, Reading\/Writing\/Waiting og accepterede anmodninger. I logfilerne holder jeg st\u00f8jniveauet lavt: En kompakt <em>log_format<\/em> med tid, status, upstream-tider og bytes er det tilstr\u00e6kkeligt til de fleste analyser. Ved meget h\u00f8je QPS-v\u00e6rdier deaktiverer jeg adgangsloggen selektivt (baseret p\u00e5 placering) eller bufferer logfilerne asynkront, s\u00e5 I\/O ikke bremser systemet. Fejlloggen indstiller jeg til <em>advarer<\/em> eller <em>fejl<\/em> og skift kun kortvarigt til <em>fejlfinding<\/em>. Jeg korrelerer l\u00f8bende latenstider (median\/95.\/99. percentil), \u00e5bne forbindelser, backend-fejlprocenter og CPU-belastning pr. worker \u2013 ud fra dette udleder jeg justeringer af de tre n\u00f8gledirektiver og opdager m\u00e6tningseffekter p\u00e5 et tidligt tidspunkt.<\/p>\n\n<h2>Containere og virtuelle milj\u00f8er: Overf\u00f8r gr\u00e6nserne korrekt<\/h2>\n<p>Jeg kontrollerer i containere de <strong>cgroup<\/strong>-Indstil gr\u00e6nserne for CPU, RAM og PID'er, og afstem dem med NGINX-indstillingerne. <em>ulimit -n<\/em> skal v\u00e6re h\u00f8j nok inden for containeren, ellers g\u00e5r mine justeringer af rlimit_nofile tabt. Ved CPU-kvoter (f.eks. 2 vCPU'er) indstiller jeg <em>arbejdsprocesser<\/em> I overensstemmelse hermed, s\u00e5 planl\u00e6gningen ikke skaber un\u00f8dvendig tr\u00e6ngsel. T\u00e6t p\u00e5 netv\u00e6rket drager jeg fordel af lavere overhead-latens i \u201ehost\u201c-netv\u00e6rksmodi, mens overlay-netv\u00e6rk medf\u00f8rer yderligere hop. P\u00e5 Multi-NUMA-v\u00e6rter er jeg opm\u00e6rksom p\u00e5 affinitet og hukommelsessokler, s\u00e5 arbejdsprocesser ikke arbejder p\u00e5 tv\u00e6rs af noder. Det samme g\u00e6lder for IRQ- og RPS\/XPS-affinitet: Hvis stierne fra NIC via IRQ til arbejdsprocessens kerne stemmer overens, falder latenstops m\u00e5lbart.<\/p>\n\n<h2>Forbindelsens livscyklus: Midlertidige porte, TIME_WAIT og reserver<\/h2>\n<p>Jeg planl\u00e6gger at have nok <strong>midlertidige porte<\/strong> (ip_local_port_range), n\u00e5r NGINX fungerer som aktiv klient over for upstream-serverne. Ved meget h\u00f8j forbindelseskapacitet undg\u00e5r jeg overdreven portfluktuation ved hj\u00e6lp af upstream-keepalive, hvilket f\u00e5r TIME_WAIT-stakken til at krympe. Jeg bruger kun kernel-toggles til \u201eReuse\u201c med forsigtighed; moderne stakke optimerer allerede meget internt. Det er mere stabilt at styre forbindelsernes varighed via fornuftige keepalive- og timeout-v\u00e6rdier og <em>reuseport<\/em> til at sikre en retf\u00e6rdig fordeling. I kapacitetsberegningen tager jeg ud over klienterne altid h\u00f8jde for upstream-siden \u2013 ofte er det FD\u2019erne der, der udg\u00f8r den egentlige begr\u00e6nsende faktor, ikke frontdoor.<\/p>\n\n<h2>Smidige genindl\u00e6sninger og implementeringer uden afbrydelser<\/h2>\n<p>Jeg bruger master\/worker-modellen til <strong>smidige genindl\u00e6sninger<\/strong>: Masteren indl\u00e6ser nye konfigurationer, gamle workere lukkes ned, mens nye problemfrit overtager. Med <em>worker_shutdown_timeout<\/em> giver jeg anmodningerne tid til at afsluttes korrekt uden at blokere ressourcer. Zero-Downtime-implementeringer p\u00e5 upstream kombinerer jeg med sundhedstjek og <em>proxy_next_upstream<\/em>-Regler, der sikrer, at enkelte fejlramte backends ikke \u00f8ger den samlede latenstid. N\u00e5r jeg \u00e6ndrer konfigurationen, \u00e6ndrer jeg altid kun \u00e9n indstilling ad gangen og verificerer effekterne i logfiler og m\u00e5linger \u2013 p\u00e5 den m\u00e5de undg\u00e5r jeg fejl som f\u00f8lge af forvirring og sikrer, at ydeevnen forbliver reproducerbar.<\/p>\n\n<h2>Kortfattet resum\u00e9<\/h2>\n<p>Jeg kobler <strong>arbejdsprocesser<\/strong> Indstil antallet af kerner (helst automatisk), s\u00e6t worker_connections i overensstemmelse med spidsbelastningen, og \u00f8g rlimit_nofile samt operativsystemets gr\u00e6nser gener\u00f8st. I Events-blokken bruger jeg epoll og multi_accept, tester det hele med reproducerbare belastningstests og justerer derefter i sm\u00e5 trin. Ved proxy-arbejdsbelastninger tager jeg h\u00f8jde for ekstra deskriptorer og tester CPU-affinitet, n\u00e5r arbejdsbelastningerne er konstante. En korrekt konfigureret stack med den rette kerne, hurtig I\/O og fornuftige netv\u00e6rksparametre g\u00f8r hele forskellen. S\u00e5dan opn\u00e5r jeg <strong>NGINX<\/strong> p\u00e5lideligt inden for det ydeevneomr\u00e5de, som kr\u00e6vende websteder og API\u2019er har brug for.<\/p>","protected":false},"excerpt":{"rendered":"<p>Find ud af, hvordan du konfigurerer NGINX-arbejdsprocesser korrekt og markant forbedrer webserverens ydeevne gennem m\u00e5lrettet NGINX-optimering.<\/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":"123","_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\/da\/wp-json\/wp\/v2\/posts\/20714","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=20714"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20714\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20707"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20714"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20714"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20714"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}