{"id":20722,"date":"2026-08-17T08:35:37","date_gmt":"2026-08-17T06:35:37","guid":{"rendered":"https:\/\/webhosting.de\/nginx-worker-connections-skalierung-tausender-requests-trafficboost\/"},"modified":"2026-08-17T08:35:37","modified_gmt":"2026-08-17T06:35:37","slug":"nginx-worker-forbindelser-skalering-af-tusindvis-af-anmodninger-trafficboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/nginx-worker-connections-skalierung-tausender-requests-trafficboost\/","title":{"rendered":"NGINX Worker-forbindelser \u2013 skalering af tusindvis af anmodninger for maksimal hostingydelse"},"content":{"rendered":"<p>Jeg skalerer nginx-workere m\u00e5lrettet for at kunne h\u00e5ndtere tusindvis af samtidige anmodninger med lav <strong>Forsinkelse<\/strong> at betjene. N\u00f8glen ligger i en afstemt kombination af worker_processes, worker_connections, fildeskriptorer og <strong>Begivenheder<\/strong>.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<ul>\n  <li><strong>Kapacitet<\/strong> = worker_processes \u00d7 worker_connections, ved reverse proxy ofte bestemt af klient- og upstream-forbindelser <strong>fordoblet<\/strong>.<\/li>\n  <li><strong>Filbeskrivelser<\/strong> (worker_rlimit_nofile, ulimit) tilpasset den forventede forbindelsesbelastning <strong>l\u00f8ft<\/strong>.<\/li>\n  <li><strong>Begivenheder<\/strong>-Blokering med epoll, multi_accept og kernel-backlogs ved h\u00f8j belastning <strong>trimme<\/strong>.<\/li>\n  <li><strong>Overv\u00e5gning<\/strong> via stub_status og belastningstests til iterative <strong>Tilpasning<\/strong>.<\/li>\n  <li><strong>Skalering<\/strong> Kombinere lodret og vandret, konfiguration <strong>afkoble<\/strong>.<\/li>\n<\/ul>\n\n<h2>NGINX-arkitektur: Master, Worker og begivenheder<\/h2>\n<p>NGINX anvender en master-proces, der starter flere worker-processer og koordinerer disse effektivt med <strong>Begivenheder<\/strong> betjenes. I stedet for tr\u00e5de pr. anmodning behandler hver worker adskillige forbindelser p\u00e5 en ikke-blokerende m\u00e5de via en begivenhedsbaseret model med lav <strong>Overhead<\/strong>. Jeg indstiller direktivet `worker_processes` til `auto`, s\u00e5 NGINX udnytter CPU-kernerne, og hver enhed f\u00e5r sin egen worker. P\u00e5 den m\u00e5de fordeler jeg indg\u00e5ende forbindelser bedre og holder latenstiden nede under spidsbelastning <strong>lav<\/strong>. For en mere indg\u00e5ende gennemgang af procesplanl\u00e6gningen henviser jeg til <a href=\"https:\/\/webhosting.de\/da\/optimal-konfiguration-af-nginx-arbejdsprocesser-ydeevneforbedring\/\">Optimering af Worker-processer<\/a>, for en korrekt parallelisering bestemmer den mulige forbindelseskapacitet. Det er afg\u00f8rende, at worker_connections pr. worker er dimensioneret hensigtsm\u00e6ssigt, s\u00e5 multiplikationen med processerne giver den forventede <strong>Spidsbelastning<\/strong> d\u00e6kker.<\/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-worker-rechenzentrum-7421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kapacitetsformel: worker_processes \u00d7 worker_connections<\/h2>\n<p>Jeg beregner den omtrentlige kapacitet ved at gange worker_processes med worker_connections, idet proxyerede anmodninger ofte optager to forbindelser pr. brugeradgang og dermed halverer det effektive antal <strong>kan<\/strong>. Mange standardinstallationer starter med 512 forbindelser pr. worker, hvilket ofte er for lidt til produktive arbejdsbelastninger <strong>er<\/strong>. Praktiske startv\u00e6rdier ligger typisk mellem 1024 og 4096 og afh\u00e6nger af trafikprofilen og hardwaren. Jeg regner med en sikkerhedsmargen, alts\u00e5 mindst en faktor to i forhold til den m\u00e5lte spidsbelastning, for sikkert at kunne h\u00e5ndtere spidsbelastninger <strong>at afb\u00f8de<\/strong>. Det er stadig vigtigt at validere resultaterne ved hj\u00e6lp af tests og live-metrikker, s\u00e5 tallene ikke blot bliver en teoretisk leg <strong>blive<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Scenarie<\/strong><\/th>\n      <th><strong>arbejdsprocesser<\/strong><\/th>\n      <th><strong>arbejdstager_forbindelser<\/strong><\/th>\n      <th><strong>Teoretisk maks.<\/strong><\/th>\n      <th><strong>Effektiv (proxy)<\/strong><\/th>\n      <th><strong>FD pr. medarbejder<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Lille hjemmeside<\/td>\n      <td>2<\/td>\n      <td>1024<\/td>\n      <td>2048<\/td>\n      <td>~1024<\/td>\n      <td>\u22651024<\/td>\n    <\/tr>\n    <tr>\n      <td>API ved middel belastning<\/td>\n      <td>4<\/td>\n      <td>2048<\/td>\n      <td>8192<\/td>\n      <td>~4096<\/td>\n      <td>\u22652048<\/td>\n    <\/tr>\n    <tr>\n      <td>Spidsbelastningstider i butikken<\/td>\n      <td>8<\/td>\n      <td>4096<\/td>\n      <td>32768<\/td>\n      <td>~16384<\/td>\n      <td>\u22654096<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>HTTP\/1.1, HTTP\/2 og TLS: Indvirkning p\u00e5 arbejdere og latenstid<\/h2>\n<p>Protokoller bestemmer forbindelsesprofilen. Med HTTP\/1.1 ser jeg ofte mange samtidige TCP-forbindelser pr. klient, mens HTTP\/2 reducerer antallet til f\u00e5, men til geng\u00e6ld mere udnyttede streams <strong>bundter<\/strong>. Det sparer p\u00e5 filbeskrivere, men l\u00e6gger i stedet en st\u00f8rre byrde p\u00e5 buffere og prioritering. Under TLS s\u00f8rger jeg for at genbruge sessioner, s\u00e5 dyre h\u00e5ndtryk ikke skal udf\u00f8res ved hver eneste foresp\u00f8rgsel <strong>s\u00e6tte farten ned<\/strong>. En f\u00e6lles session-cache og passende timeouts reducerer CPU-spidsbelastninger. Desuden indstiller jeg keepalive_requests ikke for lavt, s\u00e5 langvarige forbindelser kan udnytte deres fordele <strong>spille ud<\/strong>. For HTTP\/2 beregner jeg en h\u00f8jere grad af samtidighed pr. forbindelse og s\u00f8rger for, at sende- og modtagelsesbufferne er store nok, uden at optage for meget hukommelse <strong>spilde<\/strong>. Ved blandet trafik planl\u00e6gger jeg konservativt og verificerer virkningerne for hver protokolvariant i <strong>Test<\/strong>.<\/p>\n\n<h2>Indstilling af filbeskrivere og ulimit korrekt<\/h2>\n<p>Hver forbindelse kr\u00e6ver mindst \u00e9n filbeskrivelse, og ved reverse proxy ofte to, hvorfor lave ulimit-v\u00e6rdier kan v\u00e6re et stort problem <strong>Gr\u00e6nser<\/strong> indstille. Jeg \u00f8ger worker_rlimit_nofile, s\u00e5 worker_processes \u00d7 worker_connections kan realiseres, og der er reserver til logfiler, sockets og caches. P\u00e5 systemniveau tilpasser jeg limits.conf og fs.file-max, s\u00e5 operativsystemet tillader det planlagte antal \u00e5bne filer og ikke afbryder f\u00f8r tid <strong>Bremser<\/strong>. Ved hj\u00e6lp af `ulimit -n` samt Systemd-parametre (LimitNOFILE) kontrollerer jeg, om konfigurationen er vedvarende og passer til NGINX. Hvis man ignorerer denne indstilling, vil man pludselig opleve afviste forbindelser og stigende <strong>Forsinkelser<\/strong>.<\/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_connections_3894.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Finjustering af events-blokken: epoll, multi_accept, backlogs<\/h2>\n<p>Under Linux bruger jeg epoll, da denne mekanisme effektivt h\u00e5ndterer et stort antal forbindelser via asynkron <strong>Begivenheder<\/strong> h\u00e5ndterer. Med multi_accept on accepterer en worker flere nye forbindelser pr. begivenhed, hvilket udj\u00e6vner belastningsspidser og forsinkelser ved modtagelsen <strong>s\u00e6nker<\/strong>. Jeg justerer kerneparametre som net.core.somaxconn og net.ipv4.tcp_max_syn_backlog, s\u00e5 Accept-k\u00f8er ikke l\u00f8ber over under trafikspidser. TIME_WAIT-optimeringer som tcp_tw_reuse mindsker portflaskehalse og holder gennemstr\u00f8mningskurven stabil <strong>h\u00f8j<\/strong>. Hvis man \u00f8nsker en mere indg\u00e5ende baggrundsviden om parallelitet og k\u00f8er, er det v\u00e6rd at kigge p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/threadpool-webserver-apache-nginx-litespeed-optimering-konfiguration\/\">Optimering af tr\u00e5dpuljen<\/a>, selvom NGINX prim\u00e6rt fungerer p\u00e5 basis af begivenheder og derfor er meget ressourcebesparende <strong>skaleret<\/strong>.<\/p>\n\n<h2>Korrekt fordeling af listen-sockets: reuseport, backlog og accept_mutex<\/h2>\n<p>N\u00e5r der er rigtig mange samtidige forbindelser, skalerer jeg modtagelsessporet aktivt. Med <strong>reuseport<\/strong> Hver worker f\u00e5r sin egen lytte-socket; dermed undg\u00e5s konkurrence ved accept, og belastningen fordeles j\u00e6vnt over alle kerner. Jeg indstiller listen-backlog eksplicit for at afb\u00f8de korte spidsbelastninger. Accept_mutex er ikke l\u00e6ngere n\u00f8dvendig i denne ops\u00e6tning. Uden `reuseport` kan accept_mutex derimod <strong>hj\u00e6lpe<\/strong>, for at d\u00e6mpe flokadf\u00e6rd ved Accept. Vigtigt: Backlog-st\u00f8rrelserne i NGINX og kernen (somaxconn) b\u00f8r <strong>passer sammen<\/strong>, ellers forsvinder effekten.<\/p>\n<pre><code>events {\n    use epoll;\n    worker_connections 4096;\n    # accept_mutex on;   # er normalt ikke n\u00f8dvendigt med reuseport\n}\n\nserver {\n    listen 443 ssl http2 reuseport backlog=65535;\n    # ...\n}\n<\/code><\/pre>\n<p>Derudover knytter jeg arbejdsprocesser til CPU-kerner efter behov (worker_cpu_affinity), s\u00e5 cache-linjer og IRQ-belastning forbliver stabile. I milj\u00f8er med st\u00e6rk NUMA-p\u00e5virkning reducerer dette un\u00f8dvendig <strong>Tv\u00e6rg\u00e5ende trafik<\/strong> i hukommelsen.<\/p>\n\n<h2>Reverse proxy, upstreams og Keep-Alive<\/h2>\n<p>Som reverse proxy opretholder NGINX ofte to forbindelser pr. anmodning: \u00e9n til klienten og \u00e9n til backend, hvilket g\u00f8r kapacitetsplanl\u00e6gningen realistisk <strong>dobbelt<\/strong> t\u00e6ller. Jeg aktiverer Keep-Alive p\u00e5 en fornuftig m\u00e5de, s\u00e5 upstream-forbindelser kan genbruges, og overhead pr. foresp\u00f8rgsel <strong>falder<\/strong>. P\u00e5 den m\u00e5de reducerer jeg belastningen p\u00e5 PHP-FPM, applikationsserveren eller mikrotjenesterne og frig\u00f8r plads til nye brugersessioner. Balancen mellem timeouts, inaktivitetstid og genbrug afg\u00f8r, hvor effektivt forbindelserne genbruges <strong>blive<\/strong>. Hvis man \u00f8nsker at l\u00e6se mere om grundl\u00e6ggende emner herom, kan man finde det i <a href=\"https:\/\/webhosting.de\/da\/http-vedvarende-forbindelser-webserver-udnyttelse-ydeevne-netvaerk\/\">Vedvarende forbindelser<\/a> praktiske r\u00e5d om udnyttelse og bedre netv\u00e6rks-<strong>Brug<\/strong>.<\/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-connections-scalability-2941.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Upstream-puljer, timeouts og gentagelsesfors\u00f8g<\/h2>\n<p>For at undg\u00e5, at Worker skal vente p\u00e5 langsomme backends, s\u00f8rger jeg for korte timeouts og velafvejede gentagelsesfors\u00f8g. Jeg holder upstream-keepalive-puljerne store nok til, at forbindelserne forbliver aktive, men ikke s\u00e5 store, at inaktive FD\u2019er optager hukommelse og slots <strong>Bind<\/strong>. Jeg begr\u00e6nser antallet af gentagelser til f\u00e5 fors\u00f8g og skifter kun over i tilf\u00e6lde af tydelige transportfejl \u2013 p\u00e5 den m\u00e5de undg\u00e5r jeg \u00bbthundering herd\u00ab-effekter ved korte udfald i backend-systemet.<\/p>\n<pre><code>upstream app_backend {\n    server 10.0.0.11:8080 max_fails=3 fail_timeout=10s;\n    server 10.0.0.12:8080 max_fails=3 fail_timeout=10s;\n    keepalive 64;  # genanvendelige upstream-forbindelser\n}\n\nserver {\n    location \/ {\n proxy_pass http:\/\/app_backend;\n proxy_connect_timeout   2s;\n        proxy_read_timeout 15s;\n proxy_send_timeout 15s;\n proxy_next_upstream     error timeout http_502 http_503;\n proxy_next_upstream_tries 2;\n    }\n}\n<\/code><\/pre>\n<p>Samtidig justerer jeg Keep-Alive-parametrene (timeouts, antal anmodninger pr. forbindelse) for hurtigt at frig\u00f8re ressourcer fra klienter, der sj\u00e6ldent er aktive, <strong>at frigive<\/strong>.<\/p>\n\n<h2>Planl\u00e6g skalering p\u00e5 en fornuftig m\u00e5de: kombiner vertikalt og horisontalt<\/h2>\n<p>N\u00e5r der er tale om h\u00f8je trafikm\u00e6ngder, foretr\u00e6kker jeg at kombinere vertikal og horisontal skalering i <strong>Betragt<\/strong>. Vertikalt skalerer jeg ved hj\u00e6lp af flere CPU-kerner, RAM, hurtige SSD\u2019er og en optimeret netv\u00e6rkskonfiguration, s\u00e5 hver enkelt worker k\u00f8rer flydende <strong>v\u00e6rker<\/strong>. Horisontalt skalerer jeg med stateless NGINX-noder, centralt administreret konfiguration og distribueret logning, s\u00e5 den samlede kapacitet stiger line\u00e6rt <strong>vokser<\/strong>. Lokale cacher og veldefinerede retningslinjer via Maps eller API g\u00f8r det muligt hurtigt at implementere \u00e6ndringer. Denne adskillelse mindsker bivirkninger og bidrager til, at nye trafikm\u00f8nstre kan h\u00e5ndteres uden oml\u00e6gninger p\u00e5 hvert enkelt knudepunkt <strong>betjene<\/strong>.<\/p>\n\n<h2>Hosting-perspektiv: Latenstid, fejlprocenter og brugeroplevelse<\/h2>\n<p>For f\u00e5 worker_connections f\u00f8rer til afviste forbindelser, timeouts og d\u00e5rligere <strong>Brugeroplevelse<\/strong>. Dynamiske applikationer som CMS eller webshops m\u00e6rker det straks, fordi et sidebes\u00f8g genererer flere backend-foresp\u00f8rgsler og slots hurtigere <strong>kort<\/strong> bliver. Derfor starter jeg med moderate v\u00e6rdier som 1024 eller 2048 pr. worker og \u00f8ger disse gradvist p\u00e5 baggrund af reelle m\u00e5lev\u00e6rdier. Samtidig sikrer jeg, at upstream-tjenesterne fungerer effektivt, og s\u00f8rger for tilstr\u00e6kkelige fildeskriptorer, s\u00e5 der ikke opst\u00e5r kunstige <strong>Gr\u00e6nser<\/strong> virker. Benchmark-tests viser, at omhyggeligt tilpassede platforme giver reelle fordele her og h\u00e5ndterer spidsbelastninger p\u00e5lideligt <strong>afsk\u00e6rmning<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_worker_connections_performance_2394.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hukommelse, buffering og I\/O-stier<\/h2>\n<p>Hver forbindelse optager RAM til metadata og buffere. Jeg dimensionerer proxy_buffers, client_body_buffer_size og large_client_header_buffers, s\u00e5 typiske anmodninger kan rummes, uden at der generelt bruges for meget RAM p\u00e5 grund af afvigende anmodninger. <strong>Bind<\/strong>. For statisk indhold fremskynder sendfile og tcp_nopush leveringen, mens tcp_nodelay er velegnet til sm\u00e5 svar, hvor ventetiden er afg\u00f8rende <strong>Vigtigt<\/strong> forbliver. Hvis data ligger p\u00e5 en langsommere lagringsenhed, hj\u00e6lper aio threads plus thread_pool med at afb\u00f8de blokerende effekter. Med open_file_cache reducerer jeg filadgange og stat()-kald, men v\u00e6r opm\u00e6rksom p\u00e5 det ekstra behov for filh\u00e5ndteringsdeskriptorer (FD). Jeg skriver logfiler med buffering (access_log \u2026 buffer=\u2026 flush=\u2026), s\u00e5 I\/O-spidsbelastninger ikke p\u00e5virker responstiderne <strong>p\u00e5virke<\/strong>.<\/p>\n\n<h2>Balance mellem sikkerhed og TLS-ydeevne<\/h2>\n<p>TLS-h\u00e5ndtryk er CPU-kr\u00e6vende. Jeg kombinerer genbrug af sessioner med moderate n\u00f8gleparametre og aktiverer optimeringer, der kan stables, s\u00e5som sessionscacher og billetter, forudsat at det er driftsm\u00e6ssigt <strong>passer<\/strong>. Den optimale balance mellem sikkerhed og ydeevne holder latenstiderne stabile uden at g\u00e5 p\u00e5 kompromis med krypteringskvaliteten. Ved h\u00f8jere belastning overv\u00e5ger jeg 95.- og 99.-percentilen hver for sig, da TLS-spidsbelastninger ellers ville blive skjult bag gennemsnitsv\u00e6rdierne <strong>gemme sig<\/strong>. HTTP\/2 mindsker antallet af forbindelser, men kr\u00e6ver omhyggelighed med str\u00f8mstyring og header-komprimering for at holde CPU- og hukommelsesforbruget under kontrol <strong>beholde<\/strong>.<\/p>\n\n<h2>Modstandsdygtighed under overbelastning: Gr\u00e6nser og blid aflastning<\/h2>\n<p>For at bevare latensen er det n\u00f8dvendigt med m\u00e5lrettet <strong>Formning<\/strong> uundv\u00e6rligt ved spidsbelastning. Med limit_conn begr\u00e6nser jeg antallet af parallelle forbindelser pr. n\u00f8gle (f.eks. IP eller session), mens limit_req d\u00e6mper spidsbelastninger og beskytter backend-systemerne mod synkrone <strong>Storme<\/strong>. Jeg isolerer kritiske slutpunkter ved hj\u00e6lp af strengere regler end for statiske ressourcer. Hvis der opst\u00e5r en pludselig stigning i belastningen, returnerer jeg veldefinerede 429\/503-fejlkoder med \u00bbRetry-After\u00ab i stedet for at behandle alle anmodninger ens <strong>sulte ihjel<\/strong> at lade. Jeg stopper langvarige forbindelser (lingering_close) for at frigive ressourcer p\u00e5 en kontrolleret m\u00e5de og for at forhindre Slowloris-m\u00f8nstre <strong>modbevise<\/strong>. Denne aktive shedding holder p95\/p99-latensen inden for det gr\u00f8nne omr\u00e5de, selv n\u00e5r det samlede behov til tider overstiger den nominelle kapacitet <strong>l\u00f8gne<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/hosting-performance-9047.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Container- og systemintegration: Fjerne begr\u00e6nsninger der, hvor de opst\u00e5r<\/h2>\n<p>I containere g\u00e6lder der ofte strammere begr\u00e6nsninger. Jeg tjekker cgroup-gr\u00e6nser (CPU, RAM), indstiller ulimit -n passende inden for containeren og fastl\u00e6gger LimitNOFILE i servicedfinitionen. sysctl-parametre som somaxconn og tcp_max_syn_backlog skal p\u00e5 <strong>V\u00e6rt<\/strong> tr\u00e6der i kraft; navneomr\u00e5der isolerer ikke altid disse indstillinger p\u00e5 en gennemsigtig m\u00e5de. P\u00e5 orkestrerede platforme planl\u00e6gger jeg kapaciteten pr. pod\/node, tildeler arbejdsprocesser til bestemte kerner og s\u00f8rger for stabile netv\u00e6rksveje (f.eks. ingen un\u00f8dvendige NAT-hop), s\u00e5 latenstidskurven <strong>stille og roligt<\/strong> forbliver. Jeg bruger worker_shutdown_timeout i forbindelse med rolling-opdateringer, s\u00e5 eksisterende forbindelser afsluttes korrekt <strong>udl\u00f8be<\/strong>.<\/p>\n\n<h2>Overv\u00e5gning og iterativ optimering<\/h2>\n<p>Uden synlighed forbliver tuning-trinene <strong>Risiko<\/strong>. Jeg aktiverer stub_status eller alternative l\u00f8sninger for l\u00f8bende at overv\u00e5ge aktive forbindelser, acceptprocenter og afvisninger. I belastningstests simulerer jeg realistiske adgangsmodeller og identificerer flaskehalse i acceptk\u00f8er, upstream-forsinkelser eller CPU-<strong>M\u00e6tning<\/strong>. Derefter justerer jeg forsigtigt worker_connections, processer, filgr\u00e6nser og TCP-parametre og kontrollerer igen, hvordan det p\u00e5virker systemet. Denne cyklus sikrer, at platformen fungerer p\u00e5lideligt og forhindrer uventede problemer p\u00e5 uheldige tidspunkter <strong>Tider<\/strong>.<\/p>\n\n<h2>Eksempel p\u00e5 konfiguration og beregningsmetode<\/h2>\n<p>Hvis jeg forventer 2000 samtidige in-flight-anmodninger i spidsbelastningsperioder og bruger en reverse proxy, regner jeg groft med 4000 forbindelsesslots plus <strong>Buffer<\/strong>. Hvis NGINX k\u00f8rer p\u00e5 fire CPU-kerner, starter jeg f.eks. med `worker_processes auto` og `worker_connections` p\u00e5 1000 til 2000 pr. worker. Jeg indstiller gr\u00e6nsen for filbeskrivere pr. worker til et tilstr\u00e6kkeligt h\u00f8jt niveau, s\u00e5 forbindelser, logfiler og interne sockets har plads nok <strong>Sted<\/strong> har. Jeg indstiller Events-blokken til epoll, aktiverer multi_accept og \u00f8ger kernel-backlogs i overensstemmelse med min spidsbelastning. Et minimalistisk uddrag kan se s\u00e5dan ud, som jeg derefter finjusterer med benchmarks <strong>Afstemning<\/strong>:<\/p>\n<pre><code>worker_processes  auto;\nworker_rlimit_nofile  65535;\n\nevents {\n    use epoll;\n    worker_connections  2048;\n    multi_accept on;\n}\n\nhttp {\n    keepalive_timeout   65;\n    sendfile on;\n    # yderligere proxy-\/cache-indstillinger ...\n}\n<\/code><\/pre>\n<p>Derudover tilf\u00f8jer jeg optimeringer af lister og upstream for at finpudse modtagelses- og backend-stien under belastning:<\/p>\n<pre><code>events {\n    use epoll;\n    worker_connections 4096;\n    # worker_cpu_affinity auto;  # tildel kerner fast efter behov\n}\n\nhttp {\n    # Eksempler p\u00e5 TLS-\/session-optimeringer\n    ssl_session_cache    shared:SSL:50m;\n    ssl_session_timeout  1h;\n\n upstream app_backend {\n server 10.0.0.11:8080;\n server 10.0.0.12:8080;\n keepalive 64;\n    }\n\n    server {\n listen 443 ssl http2 reuseport backlog=65535;\n\n location \/ {\n proxy_pass http:\/\/app_backend;\n proxy_connect_timeout     2s;\n            proxy_read_timeout 15s;\n proxy_next_upstream error timeout http_502 http_503;\n proxy_next_upstream_tries 2;\n }\n    }\n}\n<\/code><\/pre>\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\/developer_desk_nginx_5823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort sagt: Konkrete retningslinjer<\/h2>\n<p>Jeg tilpasser `worker_processes` til antallet af CPU-kerner og indstiller `worker_connections` typisk til mellem 1024 og <strong>4096<\/strong>. Ved reverse proxy planl\u00e6gger jeg to forbindelser pr. anmodning og s\u00f8rger for mindst det dobbelte af det m\u00e5lte spidsbelastnings-<strong>Belastning<\/strong>. Jeg indstiller worker_rlimit_nofile samt systemomfattende gr\u00e6nser h\u00f8jt nok til, at tallene fra nginx.conf forbliver reelt anvendelige. Jeg tilpasser Events-blokken til epoll og multi_accept, mens kernel-backlogs h\u00e5ndterer korte trafikspidser <strong>afb\u00f8de<\/strong>. Ved hj\u00e6lp af overv\u00e5gning og gradvise justeringer skaber jeg derudfra en p\u00e5lidelig trafikmotor, der p\u00e5 en velfungerende m\u00e5de h\u00e5ndterer det stigende antal bes\u00f8gende <strong>b\u00e6rer<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan du konfigurerer nginx-worker-forbindelser korrekt, s\u00e5 du kan skalere NGINX sikkert og maksimere hostingydelsen ved tusindvis af anmodninger.<\/p>","protected":false},"author":1,"featured_media":20715,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20722","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":"99","_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":"20715","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20722","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=20722"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20722\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20715"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20722"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20722"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20722"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}