{"id":21459,"date":"2026-09-16T15:03:59","date_gmt":"2026-09-16T13:03:59","guid":{"rendered":"https:\/\/webhosting.de\/nginx-keepalive-requests-optimieren-webserver-performance-tuning\/"},"modified":"2026-09-16T15:03:59","modified_gmt":"2026-09-16T13:03:59","slug":"optimering-af-nginx-keepalive-anmodninger-ydeevneoptimering-af-webserveren","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/nginx-keepalive-requests-optimieren-webserver-performance-tuning\/","title":{"rendered":"Optimering af NGINX Keepalive-anmodninger: Optimal webserverydelse gennem m\u00e5lrettet finjustering"},"content":{"rendered":"<p>Med <strong>nginx keepalive<\/strong> Jeg s\u00e6nker omkostningerne ved oprettelse af forbindelser, reducerer antallet af h\u00e5ndtryk og fremskynder svartiderne m\u00e6rkbart. M\u00e5lrettet tilpassede timeouts, anmodningsbegr\u00e6nsninger pr. forbindelse og genbrugte upstream-sockets giver m\u00e5lbare ydeevneforbedringer uden behov for ny hardware.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>Timeouts<\/strong> V\u00e6lg med omtanke: Tomgangstid s\u00e5 kort som n\u00f8dvendigt, s\u00e5 lang som nyttigt.<\/li>\n  <li><strong>Foresp\u00f8rgsler<\/strong> Begr\u00e6ns pr. forbindelse: Holdbare sockets, ingen frysninger.<\/li>\n  <li><strong>Upstream-puljer<\/strong> Aktiv\u00e9r: Permanente backend-forbindelser pr. worker.<\/li>\n  <li><strong>Arbejder<\/strong> og tilpasse forbindelserne: Nok slots til inaktive og aktive klienter.<\/li>\n  <li><strong>Overv\u00e5gning<\/strong> Etablere: Overv\u00e5ge forbindelseshastighed, ventetid og fejl.<\/li>\n<\/ul>\n\n<h2>NGINX Keepalive: Effekt og omkostninger<\/h2>\n\n<p>Jeg holder bevidst TCP-forbindelser \u00e5bne, fordi <strong>H\u00e5ndtryk<\/strong> er er dyre og dominerer ved mange sm\u00e5 foresp\u00f8rgsler. Persistente sockets sparer ikke kun RTT\u2019er, de udj\u00e6vner ogs\u00e5 CPU-belastningen, da kryptografi til TLS sj\u00e6ldnere skal startes. Hver \u00e5ben forbindelse optager dog <strong>Ressourcer<\/strong>, f.eks. filbeskrivere og buffere, som jeg skal holde \u00f8je med. Kunsten ligger i balancen: tilstr\u00e6kkelig genbrug for at sikre hastighed og tilstr\u00e6kkeligt budget til nye forbindelser ved spidsbelastninger. Den, der finder den rette balance, opn\u00e5r konstant lave TTFB-v\u00e6rdier og en hurtig brugeroplevelse.<\/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\/09\/nginx-keepalive-optimierung-4271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>HTTP\/2 og HTTP\/3: Multiplexing m\u00f8der Keepalive<\/h2>\n\n<p>Med <strong>HTTP\/2<\/strong> og <strong>HTTP\/3<\/strong> Antallet af n\u00f8dvendige forbindelser pr. klient falder, fordi flere streams k\u00f8rer over \u00e9n forbindelse. Keepalive er dog stadig relevant: Den ene forbindelse b\u00f8r forblive \u00e5ben p\u00e5lideligt, ellers g\u00e5r fordelen ved multiplexing tabt p\u00e5 grund af hyppige genopkoblinger.<\/p>\n<p>Jeg holder \u00f8je med de specifikke idle-parametre for moderne protokoller og s\u00f8rger for, at v\u00e6rdierne passer til mine klient-timeouts. Ved test starter jeg med moderate v\u00e6rdier og \u00f8ger dem, n\u00e5r belastningen er stabil, indtil antallet af genopkoblinger falder, og latenstiderne forbliver konstante.<\/p>\n\n<pre><code>http {\n    # HTTP\/2: Idle-tid for ubrugte, men \u00e5bne streams\n    http2_idle_timeout 60s;\n\n    # HTTP\/3\/QUIC: lignende logik for UDP-baserede forbindelser\n    http3_idle_timeout 60s;\n\n    # TLS-genoptagelse reducerer omkostningerne ved h\u00e5ndtryk ved nye forbindelser\n    ssl_session_cache shared:SSL:50m;\n    ssl_session_timeout 1d;\n    ssl_session_tickets off;\n}\n<\/code><\/pre>\n\n<p>Multiplexing reducerer det n\u00f8dvendige antal parallelle TCP\/QUIC-forbindelser, men ikke betydningen af <strong>korrekte timeouts<\/strong>. Hvis man bruger HTTP\/2\/3, kan man ofte indstille klient-timeouts lidt mere gener\u00f8st, fordi mange sm\u00e5 ressourcer sendes via samme kanal. Vigtigt: Det skal stadig v\u00e6re muligt at m\u00e5le <em>Tid til f\u00f8rste byte<\/em>, fejlprocenter og \u00e5bne streams pr. forbindelse.<\/p>\n\n<h2>Indstil Client-Keepalive korrekt<\/h2>\n\n<p>For browser-klienter styrer jeg genbrug via <strong>keepalive_timeout<\/strong> og <strong>keepalive_requests<\/strong>, s\u00e5 sockets holder l\u00e6nge nok uden at blokere i evigheder. Som udgangspunkt bruger jeg en timeout p\u00e5 30\u201360 sekunder og 100\u2013300 anmodninger pr. forbindelse, hvorefter jeg justerer ud fra m\u00e5lingerne. En detaljeret oversigt findes her <a href=\"https:\/\/webhosting.de\/da\/http-keepalive-timeout-konfiguration-af-serverens-ydeevne\/\">Vejledning i Keepalive-timeout<\/a>, der forklarer virkningerne p\u00e5 ventetiden og serverressourcerne. Kortere timeouts er velegnede ved meget mange korte opkald, mens l\u00e6ngere tidsvinduer er en fordel ved periodiske API-adgange. Til at begynde med indstiller jeg klare standardv\u00e6rdier og m\u00e5ler effekten p\u00e5 \u00e5bne forbindelser samt fejlm\u00f8nstre.<\/p>\n\n<pre><code>http {\n    # Inaktive forbindelser til klienten\n    keepalive_timeout 60s;\n    # \u00d8vre gr\u00e6nse for antal anmodninger pr. TCP-forbindelse\n    keepalive_requests 200;\n\n    # Valgfrit: Fjern Keep-Alive for bestemte klienter (\u00e6ldre fejl)\n    # keepalive_disable msie6;\n}\n<\/code><\/pre>\n\n<h2>Upstream-keepalive i reverse-proxyen<\/h2>\n\n<p>Mellem NGINX og backend-apps bruger jeg persistente upstream-sockets, fordi opkoblingen til PHP-FPM, Node.js eller Python-tjenester ligeledes <strong>Forsinkelse<\/strong> koster. Til det aktiverer jeg i upstream-poolen et passende antal genanvendelige forbindelser pr. worker. Det er vigtigt, at HTTP\/1.1 sendes bagud, og at Connection-headeren er tom, ellers afbryder klientens anmodning om \u201eclose\u201c backend-persistensen. Jeg tager udgangspunkt i antallet af samtidige anmodninger og indstiller puljen s\u00e5ledes, at der n\u00e6sten ikke opst\u00e5r nye forbindelser. P\u00e5 den m\u00e5de falder backend-forbindelsestiden, og hele k\u00e6den leverer hurtigere <strong>Svar p\u00e5 sp\u00f8rgsm\u00e5l<\/strong>.<\/p>\n\n<pre><code>upstream backend {\n    server 127.0.0.1:9000;\n    keepalive 64; # Antal vedvarende upstream-forbindelser pr. worker\n}\n\nserver {\n    location \/ {\n proxy_pass http:\/\/backend;\n        proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n # TCP-keepalive for upstream-sockets p\u00e5 OS-niveau\n proxy_socket_keepalive on;\n    }\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx_optimierung_miniature_4891.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionering af bassinet og budget for tilslutning<\/h2>\n\n<p>Jeg beregner puljer p\u00e5 en realistisk m\u00e5de: Antallet af vedvarende upstream-forbindelser beregnes ud fra <strong>worker_processes \u00d7 keepalive<\/strong> pr. upstream. Hvis man bruger 8 workere og keepalive 64, holder man op til 512 sockets \u00e5bne pr. upstream \u2013 pr. instans. Bag en load balancer eller ved flere upstream-m\u00e5l kan det hurtigt l\u00f8be op.<\/p>\n<p>Mit m\u00e5l: nok ledige sockets til, at st\u00f8rstedelen af foresp\u00f8rgslerne <em>uden ny Connect<\/em> opfyldes, men der stadig er plads til spidsbelastninger. Jeg overv\u00e5ger m\u00e5let \u201enye upstream-forbindelser pr. sekund\u201c og s\u00e6nker det, indtil yderligere for\u00f8gelser af poolst\u00f8rrelsen ikke l\u00e6ngere medf\u00f8rer nogen n\u00e6vnev\u00e6rdig forbedring af latenstiden.<\/p>\n<p>Jeg tager ogs\u00e5 h\u00f8jde for <strong>Retf\u00e6rdighed<\/strong>: For store puljer kan stille nyankomne klienter i en ugunstig situation, fordi worker-slots optages af inaktive forbindelser. En moderat gr\u00e6nse med aktiv overv\u00e5gning er som regel hurtigere end at indstille maksimale v\u00e6rdier p\u00e5 en mavefornemmelse.<\/p>\n\n<h2>Finjustering: Timeouts og anmodningsgr\u00e6nser<\/h2>\n\n<p>Jeg kombinerer timeout og anmodningsbegr\u00e6nsning p\u00e5 en s\u00e5dan m\u00e5de, at forbindelser effektivt genbruges uden at <strong>Langrendsl\u00f8ber<\/strong> at blive. H\u00f8je v\u00e6rdier p\u00e5 begge akser minimerer antallet af forbindelser, men \u00f8ger risikoen for fastl\u00e5ste sockets ved netv\u00e6rksproblemer. Lave v\u00e6rdier sikrer friske forbindelser, men kr\u00e6ver ekstra h\u00e5ndtryk. Jeg g\u00e5r frem i sm\u00e5 skridt, observerer fejl og justerer med j\u00e6vne mellemrum. Den f\u00f8lgende tabel viser fornuftige startintervaller for forskellige brugsm\u00f8nstre og giver et kompakt <strong>Orientering<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Scenarie<\/th>\n      <th>keepalive_timeout<\/th>\n      <th>keepalive_requests<\/th>\n      <th>Hint<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Mange korte sidevisninger<\/td>\n      <td>10\u201330 sekunder<\/td>\n      <td>100-300<\/td>\n      <td>Hurtig genbrug, lav idle-binding<\/td>\n    <\/tr>\n    <tr>\n      <td>Typisk hjemmeside<\/td>\n      <td>60\u2013120 sekunder<\/td>\n      <td>200\u2013400<\/td>\n      <td>Et godt gennemsnit for Assets og HTML<\/td>\n    <\/tr>\n    <tr>\n      <td>API med periodiske opkald<\/td>\n      <td>60\u2013120 sekunder<\/td>\n      <td>300\u20131000<\/td>\n      <td>H\u00f8jere genbrugsprocent for kunder<\/td>\n    <\/tr>\n    <tr>\n      <td>Interne tjenester \/ gateways<\/td>\n      <td>30\u201390 sekunder<\/td>\n      <td>500\u20131000+<\/td>\n      <td>Konstans er vigtigere end minimale forbindelser<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Arbejderoptimering og forbindelser<\/h2>\n\n<p>Jeg satte <strong>arbejdsprocesser<\/strong> p\u00e5 \u00bbauto\u00ab eller p\u00e5 antallet af CPU-kerner, og s\u00f8rg for, at der er tilstr\u00e6kkelig <strong>arbejdstager_forbindelser<\/strong> fordi inaktive sockets optager slots. For lave gr\u00e6nser forhindrer nye forbindelser, selvom der stadig er ledig CPU-kapacitet. Hvis man k\u00f8rer store keepalive-puljer, skal man have tilstr\u00e6kkeligt med deskriptorer og event-slots pr. worker. En god introduktion findes i \u201e<a href=\"https:\/\/webhosting.de\/da\/nginx-worker-forbindelser-skalering-af-tusindvis-af-anmodninger-trafficboost\/\">Skalering af Worker-Connections<\/a>\u201c, der forklarer sammenh\u00e6ngene mellem begivenheder, forbindelser og belastning. Velgennemt\u00e6nkte v\u00e6rdier sikrer, at genbrug af inaktivitet og nye forbindelser kan eksistere side om side.<\/p>\n\n<pre><code>worker_processes auto;\n\nevents {\n    worker_connections 4096;\n    # Valgfrit: reuseport kan forbedre fordelingen p\u00e5 kernelniveau\n    # multi_accept on;\n}\n\nhttp {\n    keepalive_timeout 60s;\n    keepalive_requests 200;\n\n upstream backend {\n server 127.0.0.1:9000;\n keepalive 64;\n    }\n}\n<\/code><\/pre>\n\n<h2>Optimering af operativsystem og socket<\/h2>\n\n<p>Jeg tjekker systemgr\u00e6nserne, s\u00e5 Keepalive kan udnytte sit fulde potentiale. For f\u00e5 deskriptorer eller overfyldte socket-k\u00f8er medf\u00f8rer <strong>kunstige flaskehalse<\/strong>. Ud over ulimit og worker_rlimit_nofile spiller kernebegr\u00e6nsninger en afg\u00f8rende rolle.<\/p>\n\n<pre><code># Eksempler p\u00e5 sysctl-v\u00e6rdier (juster med forsigtighed og efter afpr\u00f8vning)\nfs.file-max = 1000000\nnet.core.somaxconn = 65535\nnet.core.netdev_max_backlog = 16384\nnet.ipv4.ip_local_port_range = 1024 65000\nnet.ipv4.tcp_fin_timeout = 15\nnet.ipv4.tcp_tw_reuse = 1\nnet.ipv4.tcp_max_syn_backlog = 262144\n<\/code><\/pre>\n\n<p>Jeg tilpasser disse v\u00e6rdier til omgivelserne: Mange kortvarige forbindelser drager fordel af et bredere portinterval og korte FIN-\/TIME_WAIT-tider. Ved upstream-keepalive reducerer jeg <em>Neuconnects<\/em>, hvilket mindsker TIME_WAIT-belastningen. Derudover tager jeg h\u00f8jde for <strong>NAT<\/strong>-Enheder mellem proxy og backend: For strenge timeout-indstillinger for inaktivitet i netv\u00e6rket afbryder forbindelserne p\u00e5 uforudsigelig vis. En moderat anmodningsgr\u00e6nse pr. socket og TCP-keepalives (<code>proxy_socket_keepalive on;<\/code>) forhindrer, at forbindelserne bliver \u201efor\u00e6ldede\u201c.<\/p>\n\n<h2>Indstil header og HTTP-version korrekt<\/h2>\n\n<p>Jeg er opm\u00e6rksom p\u00e5 <strong>HTTP\/1.1<\/strong> til backend, fordi Upstream-Keepalive kun fungerer med det. Derudover fjerner jeg aktiv forbindelsesstyring via header, s\u00e5 NGINX selvst\u00e6ndigt administrerer persistensen. P\u00e5 klientsiden lader jeg Keep-Alive k\u00f8re i overensstemmelse med standarden og begr\u00e6nser levetiden via timeout og anmodningsbegr\u00e6nsning. Derudover kontrollerer jeg backend-idle-timeouts og indstiller dem til en v\u00e6rdi, der er minimalt h\u00f8jere end NGINX, for at undg\u00e5 reset-fejl. Rene headers sikrer <strong>Genbrug<\/strong> uden u\u00f8nskede lukninger.<\/p>\n\n<pre><code># Eksempel: Proxy-placering med korrekte headere\nlocation \/api\/ {\n    proxy_pass http:\/\/backend;\n    proxy_http_version 1.1;\n    proxy_set_header Connection \"\";\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-keepalive-optimization-7123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Forskel: HTTP Keep-Alive vs. TCP-Keepalive<\/h2>\n\n<p>Jeg skelner skarpt mellem <strong>HTTP Keep-Alive<\/strong> (flere HTTP-anmodninger pr. forbindelse) og <strong>TCP-Keepalive<\/strong> (Test p\u00e5 operativsystemniveau for at opdage inaktive modparter). HTTP Keep-Alive styrer jeg med <code>keepalive_timeout<\/code> og <code>keepalive_requests<\/code>, mens TCP-keepalives, afh\u00e6ngigt af stakken, g\u00e5r over <code>proxy_socket_keepalive on;<\/code> og systemparametre. For backends, der k\u00f8rer over ustabile netv\u00e6rk, aktiverer jeg TCP-keepalives for hurtigere at rydde fastl\u00e5ste sockets.<\/p>\n\n<h2>Langvarige processer og s\u00e6rlige tilf\u00e6lde: WebSockets, SSE, gRPC<\/h2>\n\n<p>WebSockets og server-sendte begivenheder er <strong>Langrendsl\u00f8ber<\/strong>, der holder en forbindelse \u00e5ben i lang tid \u2013 her spiller klassisk Reuse en underordnet rolle. Jeg s\u00f8rger for passende <code>proxy_read_timeout<\/code> og beskyt mig med <code>send_timeout<\/code> mod <em>Slowloris<\/em>-effekter. For gRPC (baseret p\u00e5 HTTP\/2) g\u00e6lder overvejelserne vedr\u00f8rende multiplexing; jeg indstiller idle-timeouts s\u00e5ledes, at streams ikke lukkes un\u00f8digt ned.<\/p>\n\n<pre><code>location \/ws\/ {\n    proxy_pass http:\/\/backend;\n    proxy_http_version 1.1;\n    proxy_set_header Upgrade $http_upgrade;\n    proxy_set_header Connection \"upgrade\";\n    proxy_read_timeout 300s;\n    send_timeout 30s;\n}\n<\/code><\/pre>\n\n<h2>Overv\u00e5gning og m\u00e5linger<\/h2>\n\n<p>Jeg m\u00e5ler succesen ud fra n\u00f8gletal som andelen af nye upstream-forbindelser, <strong>upstream_connect_time<\/strong> og andelen af \u00e5bne forbindelser pr. worker. Faldende forbindelsesrater ved u\u00e6ndret eller stigende antal anmodninger tyder p\u00e5 vellykket genbrug. Markante timeouts eller forbindelsesnulstillinger indikerer uoverensstemmende timeouts mellem NGINX og backend. Derudover overv\u00e5ger jeg hukommelse, filbeskrivere og begivenhedsk\u00f8er under belastning. Ved regelm\u00e6ssig kontrol opdager man tendenser tidligt og forhindrer dyre <strong>Fejl og mangler<\/strong>.<\/p>\n\n<h2>Forbedringer af logfiler for at skabe st\u00f8rre gennemsigtighed ved genbrug<\/h2>\n\n<p>For at f\u00e5 et bedre overblik udvider jeg adgangsloggen med oplysninger om forbindelserne. P\u00e5 den m\u00e5de kan jeg se, hvor ofte en TCP-forbindelse genbruges, og hvordan forbindelsestiderne udvikler sig.<\/p>\n\n<pre><code>log_format keepalive_fmt\n  '$remote_addr $host \"$request\" $status $body_bytes_sent '\n  '$request_time $upstream_connect_time '\n  'conn:$connection reqs:$connection_requests';\n\naccess_log \/var\/log\/nginx\/access_keepalive.log keepalive_fmt;\n<\/code><\/pre>\n\n<p>Jeg observerer median- og P95\/P99-v\u00e6rdier for <em>upstream_connect_time<\/em> samt fordelingen af <em>$-forbindelsesanmodninger<\/em>. Stigende Reuse-tal ved stabil latenstid betyder, at puljer og timeouts er valgt korrekt.<\/p>\n\n<h2>Typiske snublesten og l\u00f8sninger<\/h2>\n\n<p>For store puljer fylder forbindelsesslots, mens nye klienter venter, derfor holder jeg st\u00f8rrelserne moderate og justerer dem l\u00f8bende. Forskellige timeout-v\u00e6rdier for inaktivitet mellem proxyen og backend\u2019et medf\u00f8rer genstart, s\u00e5 jeg indstiller backend\u2019et til en v\u00e6rdi, der er minimalt h\u00f8jere end <strong>NGINX<\/strong>. Et glemt \u201eConnection: close\u201c i proxy-headeren afbryder persistensen, derfor sletter jeg konsekvent dette element fra headeren. TLS-forhandling kan belaste CPU\u2019en ved mange nye forbindelser, hvilket jeg afb\u00f8der ved at \u00f8ge genbrugsandelen. Ved sporadiske netv\u00e6rksfejl hj\u00e6lper en moderat anmodningsgr\u00e6nse pr. socket, s\u00e5 gamle <strong>Sessioner<\/strong> ikke leve for evigt.<\/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\/09\/nginx_keepalive_optimierung_4723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktisk orienterede konfigurationer<\/h2>\n\n<p>For meget bes\u00f8gte websteder v\u00e6lger jeg en kort timeout og en middelh\u00f8j anmodningsgr\u00e6nse, s\u00e5 ressourcerne k\u00f8rer effektivt. Ved API\u2019er med tilbagevendende opkald h\u00e6ver jeg gr\u00e6nsen for yderligere at reducere TCP- og TLS-handshakes. Jeg dimensionerer upstream-puljer ud fra den forventede parallelitet og tester med realistisk trafik. Hvert milj\u00f8 opf\u00f8rer sig forskelligt, derfor tjekker jeg latenstiden og fejlm\u00f8nstrene efter \u00e6ndringer. To eksempler viser <strong>Startv\u00e6rdier<\/strong>, som jeg derefter finjusterer ved hj\u00e6lp af m\u00e5lepunkter.<\/p>\n\n<pre><code>#-scenarie 1: H\u00f8jt bes\u00f8gt websted\nhttp {\n    keepalive_timeout 30s;\n    keepalive_requests 300;\n\n upstream app {\n server 127.0.0.1:8080;\n        keepalive 32;\n    }\n\n server {\n listen 443 ssl http2;\n Hold \u00f8je med # HTTP\/2-inaktivitet\n http2_idle_timeout 45s;\n    }\n}\n<\/code><\/pre>\n\n<pre><code># Scenarie 2: API med periodiske opkald\nhttp {\n    keepalive_timeout 75s;\n    keepalive_requests 1000;\n\n    upstream api_backend {\n server 127.0.0.1:9001;\n keepalive 64;\n    }\n\n    server {\n listen 443 ssl http2;\n # Lidt l\u00e6ngere inaktivitetsvindue for tilbagevendende opkald\n http2_idle_timeout 75s;\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\/09\/serverraum-nginx-3721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tjekliste til iterativ optimering<\/h2>\n\n<p>Jeg starter med en analyse af den nuv\u00e6rende situation: Trafikm\u00f8nstre, svartider og fejlprocent s\u00e6tter retningen. Derefter indstiller jeg klient-timeout og anmodningsgr\u00e6nse til solide startv\u00e6rdier og aktiverer upstream-puljer. Jeg indstiller backend-idle-timeouts lidt h\u00f8jere end NGINX, s\u00e5 der ikke opst\u00e5r uventede <strong>Nulstillinger<\/strong> opst\u00e5r. Derefter overv\u00e5ger jeg forbindelseshastigheder, forbindelsestid og \u00e5bne sockets pr. worker. Hvis man \u00f8nsker at dykke dybere ned i genbrugsgraden, kan man finde inspiration omkring <a href=\"https:\/\/webhosting.de\/da\/http-forbindelse-genbrug-keepalive-optimering-serverperf-boost\/\">Genbrug af forbindelser<\/a> og fornuftige \u00f8vre gr\u00e6nser.<\/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\/09\/nginx_keepalive_opt_5731.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Yderligere diagnose: Mismatch og tidsadf\u00e6rd<\/h2>\n\n<p>N\u00e5r forbindelser tilsyneladende afbrydes \u201euden grund\u201c, leder jeg efter <strong>Uoverensstemmelser<\/strong> i k\u00e6den: Client-Idle vs. NGINX-Timeout vs. Backend-Idle og mellemliggende NAT\/gateways. Jeg \u00f8ger backend-timeout-v\u00e6rdien en smule i forhold til NGINX-v\u00e6rdien, tjekker reset-koder i fejlloggen og observerer, om <em>upstream_connect_time<\/em> viser spidser. Ofte er en lille buffer (f.eks. +10\u201320%) ved backend-timeout nok til at undg\u00e5 genstart.<\/p>\n<p>Jeg bem\u00e6rker desuden, at \u201e<em>langvarig n\u00e6rhed<\/em>\u201c-faser: N\u00e5r forbindelsen lukkes, lader NGINX indg\u00e5ende data l\u00f8be ud i et kort \u00f8jeblik, hvilket optager worker-ressourcer. Et meget stort antal samtidige lukninger kan binde begivenheder. I s\u00e5danne tilf\u00e6lde justerer jeg lukkevinduerne og holder det samlede antal \u00e5bne forbindelser i balance ved hj\u00e6lp af fornuftige keepalive-v\u00e6rdier.<\/p>\n\n<h2>Resum\u00e9: Keepalive som middel til at forbedre ydeevnen<\/h2>\n\n<p>Jeg bruger Keepalive m\u00e5lrettet, fordi det reducerer omkostningerne ved oprettelse af forbindelser, mindsker latenstiden og aflaster CPU\u2019en. Kombinationen af en passende timeout, en velafbalanceret anmodningsgr\u00e6nse og passende upstream-puljer giver m\u00e6rkbare <strong>Hastighed<\/strong>. Uden overv\u00e5gning forbliver potentialet uudnyttet, derfor tjekker jeg l\u00f8bende n\u00f8gletallene og justerer v\u00e6rdierne trin for trin. Hvis man har brug for yderligere ressourcer, skal man v\u00e6re opm\u00e6rksom p\u00e5 antallet af arbejdere, forbindelsesslots og korrekt h\u00e5ndtering af headere. Professionelle ops\u00e6tninger, f.eks. hos <strong>webhoster.de<\/strong>, udnytter disse justeringsmuligheder fuldt ud og leverer hurtige, p\u00e5lidelige tjenester.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan du optimerer NGINX Keepalive-anmodninger for at \u00f8ge din webservers ydeevne markant. Med praktiske indstillinger for keepalive_timeout, keepalive_requests, Upstream-Keepalive og worker-tuning \u2013 herunder fokus p\u00e5 NGINX Keepalive som den centrale justeringsfaktor.<\/p>","protected":false},"author":1,"featured_media":21452,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21459","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":"115","_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 keepalive","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":"21452","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21459","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=21459"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21459\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21452"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21459"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21459"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21459"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}