{"id":18056,"date":"2026-03-03T18:23:49","date_gmt":"2026-03-03T17:23:49","guid":{"rendered":"https:\/\/webhosting.de\/http-keepalive-timeout-server-performance-konfiguration\/"},"modified":"2026-03-03T18:23:49","modified_gmt":"2026-03-03T17:23:49","slug":"http-keepalive-timeout-konfiguration-af-serverens-ydeevne","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/http-keepalive-timeout-server-performance-konfiguration\/","title":{"rendered":"HTTP Keep-Alive Timeout: Optimal konfiguration for serverens ydeevne"},"content":{"rendered":"<p>Med fokus p\u00e5 <strong>HTTP Keep-Alive Timeout<\/strong> Jeg viser dig, hvordan du indstiller tomgangstider, s\u00e5 forbindelser genbruges uden at blokere tr\u00e5de. Jeg forklarer specifikke v\u00e6rdier, viser typiske faldgruber og giver afpr\u00f8vede og testede konfigurationer til <strong>nginx<\/strong>, Apache og operativsystemet.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<ul>\n  <li><strong>Balance<\/strong>: For korte \u00f8ger h\u00e5ndtryk, for lange blokerer tr\u00e5de.<\/li>\n  <li><strong>V\u00e6rdier<\/strong>For det meste 5-15 s og 100-500 foresp\u00f8rgsler pr. forbindelse.<\/li>\n  <li><strong>Koordinering<\/strong>Koordiner timeouts for klient, LB og firewall.<\/li>\n  <li><strong>S\u00e6rlige tilf\u00e6lde<\/strong>WebSockets, SSE, Long Polling hver for sig.<\/li>\n  <li><strong>Overv\u00e5gning<\/strong>: Overv\u00e5g \u00e5bne sockets, FD'er og ventetider.<\/li>\n<\/ul>\n\n<h2>HTTP Keep-Alive kort forklaret<\/h2>\n<p>Jeg har TCP-forbindelser med <strong>Keep-Alive<\/strong> \u00e5ben, s\u00e5 flere anmodninger bruger den samme linje. Det sparer mig for gentagne TCP- og TLS-h\u00e5ndtryk og reducerer <strong>CPU<\/strong>-overhead m\u00e6rkbart. Det er is\u00e6r en fordel for mange sm\u00e5 filer som f.eks. ikoner, JSON eller CSS. Hver ny forbindelse, der undg\u00e5s, reducerer kontekstskift og aflaster kernerutiner. I benchmarks med en h\u00f8j andel af GET reduceres den samlede varighed betydeligt, fordi der genereres f\u00e6rre SYN\/ACK-pakker, og mere beregningstid flyder ind i applikationslogikken.<\/p>\n<p>Jeg m\u00e5ler hurtigt effekten: Den glidende gennemsnitlige latenstid bliver mere j\u00e6vn, og antallet af nye TCP-forbindelser pr. sekund falder. Jeg opn\u00e5r ikke dette ved magi, men ved at <strong>Genbrug af forbindelser<\/strong> og fornuftige gr\u00e6nser. Det er stadig vigtigt, at Keep-Alive ikke er en erstatning for hurtig rendering eller caching. Det forkorter ventetiden ved netv\u00e6rksgr\u00e6nsen, mens selve appen fortsat skal reagere effektivt. Begge dele \u00f8ger sammen <strong>Ydelse<\/strong> m\u00e6rkbart.<\/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\/03\/server-optimierung-4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Forst\u00e5 den rigtige timeout<\/h2>\n<p>Timeout definerer, hvor l\u00e6nge en inaktiv forbindelse forbliver \u00e5ben, f\u00f8r serveren lukker den. <strong>lukker<\/strong>. Hvis jeg s\u00e6tter den for kort, \u00e5bner klienterne hele tiden nye TCP-forbindelser, hvilket <strong>Overhead<\/strong> er h\u00e6vet. Hvis jeg s\u00e6tter den for lang, parkerer inaktive forbindelser dyrebare arbejdere eller tr\u00e5de. Kunsten ligger i balancen mellem genbrug og ressourceforbrug. Jeg tester praktisk: s\u00e6tter den f\u00f8rst groft, og finjusterer den derefter med belastningstests.<\/p>\n<p>Jeg er ogs\u00e5 opm\u00e6rksom p\u00e5 forholdet mellem svartider og inaktive vinduer. Hvis den typiske brugerinteraktion mellem to klik er 2-4 sekunder, d\u00e6kker en timeout p\u00e5 5-15 sekunder normalt det reelle m\u00f8nster. Korte API-kald kan sagtens t\u00e5le 5-10 sekunder, medie-workloads 10-15 sekunder. Det er vigtigt, at jeg ikke overdriver: alt for lange timeouts f\u00f8rer sj\u00e6ldent til mere <strong>Gennemstr\u00f8mning<\/strong>, men f\u00f8rer ofte til blokering <strong>Ressourcer<\/strong>. Jeg kan hurtigt genkende det p\u00e5 det stigende antal \u00e5bne stikkontakter og h\u00f8je FD-tal.<\/p>\n\n<h2>Adskil timeout-typer p\u00e5 en ren m\u00e5de<\/h2>\n<p>Jeg skelner strengt mellem <strong>Inaktiv timeout<\/strong> (Keep-Alive), <strong>Timeout for l\u00e6sning\/header<\/strong> (hvor l\u00e6nge serveren venter p\u00e5 indg\u00e5ende anmodninger) og <strong>Send\/skriv timeout<\/strong> (hvor l\u00e6nge det tolereres at sende til klienten). Disse kategorier opfylder forskellige opgaver:<\/p>\n<ul>\n  <li><strong>Inaktiv timeout:<\/strong> Styrer genbrug og parkeringsvarighed for inaktive forbindelser.<\/li>\n  <li><strong>Timeout for l\u00e6sning\/header:<\/strong> Beskytter mod langsomme klienter (slow lorises) og halvt afsendte headere.<\/li>\n  <li><strong>Send\/skriv timeout:<\/strong> Forhindrer serveren i at vente i det uendelige p\u00e5 en langsom modtagelse hos klienten.<\/li>\n<\/ul>\n<p>P\u00e5 <strong>nginx<\/strong> Jeg bruger bevidst header_timeout\/read_timeout og send_timeout pr. kontekst (http\/server\/location) ud over keepalive_timeout. Siden nyere versioner har jeg valgfrit sat <strong>keepalive_time<\/strong>, for at begr\u00e6nse den maksimale levetid for en forbindelse, selv om den forbliver aktiv. I <strong>Apache<\/strong> Jeg bruger ogs\u00e5 <strong>RequestReadTimeout<\/strong> (mod_reqtimeout), og tjek <strong>Timeout<\/strong> (global) adskilt fra <strong>KeepAliveTimeout<\/strong>. Denne adskillelse er en vigtig byggesten mod at binde ressourcer uden nogen reel fordel.<\/p>\n\n<h2>Anbefalede v\u00e6rdier i praksis<\/h2>\n<p>I produktive milj\u00f8er s\u00e6tter jeg en keep-alive timeout p\u00e5 5-15 sekunder og 100-500 foresp\u00f8rgsler pr. forbindelse. Dette interval giver en god genanvendelse af forbindelser og holder antallet af inaktive forbindelser nede. P\u00e5 <strong>nginx<\/strong> Jeg bruger keepalive_timeout 10s som startv\u00e6rdi og keepalive_requests 200. Hvis der er meget trafik, \u00f8ger jeg den moderat, hvis jeg ser for mange nye TCP-forbindelser. Hvis trafikken er sparsom, s\u00e6nker jeg den igen for at forhindre en overflod af inaktiv trafik.<\/p>\n<p>De, der g\u00e5r mere i dybden, vil have gavn af en klar indstillingsproces med m\u00e5lepunkter. Derfor sammenfatter jeg mine retningslinjer i en praktisk guide, der beskriver vejen fra m\u00e5ling til konfiguration til kontrol. For en hurtig start henviser jeg til mine trin i <a href=\"https:\/\/webhosting.de\/da\/http-keep-alive-tuning-serverbelastning-ydeevneoptimering-flow\/\">Keep-Alive-tuning<\/a>. S\u00e5dan kontrollerer du <strong>Genbrug<\/strong> og gr\u00e6nser og undg\u00e5 overraskelser. I sidste ende er det, der t\u00e6ller, lav latenstid med stabil <strong>Gennemstr\u00f8mning<\/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\/03\/http-keep-alive-optimierung-1723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Risici ved lange timeouts<\/h2>\n<p>En lang timeout holder forbindelser kunstige <strong>\u00e5ben<\/strong> og blokerer arbejdere, selv om der ikke f\u00f8lger nogen anmodning. Det f\u00e5r sockets til at svulme op og driver antallet af filbeskrivelser i vejret. Hvis processen n\u00e5r sine gr\u00e6nser, ser jeg afvisende acceptfejl eller k\u00f8er, n\u00e5r der oprettes en forbindelse. Hukommelsen vokser, garbage collectors eller allocators koster ekstra tid, og ventetiden stiger. I tilf\u00e6lde af en fejl sender klienter derefter til sockets, der allerede er lukket, og modtager kryptiske <strong>Fejl<\/strong>.<\/p>\n<p>Jeg undg\u00e5r det ved at indstille moderate v\u00e6rdier og tjekke regelm\u00e6ssige m\u00e5linger. Hvis antallet af inaktive forbindelser stiger for meget under lav belastning, s\u00e6nker jeg timeouten. Hvis jeg ser mange nye forbindelser pr. sekund under spidsbelastninger, \u00f8ger jeg den forsigtigt i sm\u00e5 trin. Det er s\u00e5dan, jeg holder <strong>Kapacitet<\/strong> brugbar og forhindrer d\u00f8de forbindelser. Resultatet er et mere smidigt system med f\u00e6rre <strong>Tips<\/strong> i svingene.<\/p>\n\n<h2>Konfiguration: nginx, Apache og OS-lag<\/h2>\n<p>Jeg starter p\u00e5 webserverniveau og indstiller timeout og gr\u00e6nser. P\u00e5 <strong>nginx<\/strong> Jeg s\u00e6tter keepalive_timeout til 5-15s og keepalive_requests til 100-500. I Apache med event-MPM kombinerer jeg KeepAlive On, KeepAliveTimeout 5-15 og MaxKeepAliveRequests 100-500. Derefter kalibrerer jeg worker- eller tr\u00e5dpools i henhold til den forventede belastning. Det forhindrer inaktive keep-alives i at blive produktive. <strong>Spilleautomater<\/strong> bindes.<\/p>\n<p>Jeg \u00f8ger gr\u00e6nser og k\u00f8er p\u00e5 operativsystemniveau. Jeg s\u00e6tter ulimit -n til mindst 100.000, justerer net.core.somaxconn og tcp_max_syn_backlog og tjekker TIME_WAIT-h\u00e5ndteringen. Dette sikrer, at kernen og processen har nok <strong>Ressourcer<\/strong> giver. Til sidst verificerer jeg stierne fra NIC'en via IRQ-balancering til appen. Dette giver mig mulighed for at genkende flaskehalse i god tid og holde <strong>Forsinkelse<\/strong> lav.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Komponent<\/th>\n      <th>Direktiv\/indstilling<\/th>\n      <th>Anbefaling<\/th>\n      <th>Hint<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>nginx<\/td>\n      <td>keepalive_timeout<\/td>\n      <td>5\u201315 s<\/td>\n      <td><strong>Kortere<\/strong> med lidt trafik, l\u00e6ngere med mange sm\u00e5 foresp\u00f8rgsler<\/td>\n    <\/tr>\n    <tr>\n      <td>nginx<\/td>\n      <td>keepalive_requests<\/td>\n      <td>100\u2013500<\/td>\n      <td>Genbruger forbindelser og reducerer <strong>L\u00e6kager<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Apache (begivenhed)<\/td>\n      <td>KeepAliveTimeout<\/td>\n      <td>5\u201315 s<\/td>\n      <td>Event-MPM h\u00e5ndterer tomgang mere effektivt end <strong>prefork<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Operativsystem<\/td>\n      <td>ulimit -n<\/td>\n      <td>\u2265 100.000<\/td>\n      <td>Flere \u00e5bne FD'er for mange <strong>Stik<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Operativsystem<\/td>\n      <td>net.core.somaxconn<\/td>\n      <td>For\u00f8gelse<\/td>\n      <td>F\u00e6rre afviste forbindelser under <strong>Spidsbelastning<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/server-optimization-http-keep-alive-4317.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Reverse proxy og upstream genbrug<\/h2>\n<p>Jeg t\u00e6nker altid keep-alive <strong>ende-til-ende<\/strong>. Der er ofte en k\u00e6de af reverse proxy \u2192 app-servere bag edge-serveren. For nginx aktiverer jeg min egen <strong>Keep Alive Pools<\/strong> (upstream keepalive, keepalive_requests, keepalive_timeout), s\u00e6t proxy_http_version 1.1 og fjern \u201eConnection: close\u201c. Dette sparer mig ogs\u00e5 for <em>Internt<\/em> handshakes og offloader app-backends (Node.js, Java, PHP-FPM). I Apache med mod_proxy beholder jeg ogs\u00e5 vedvarende forbindelser til backend-servere og begr\u00e6nser dem pr. destination, s\u00e5 et hotspot ikke monopoliserer puljerne.<\/p>\n<p>Jeg m\u00e5ler separat: Genbrugsrate Client\u2192Edge og Edge\u2192Backend. Hvis jeg ser god genanvendelse p\u00e5 kanten, men mange nye forbindelser til backenden, \u00f8ger jeg selektivt upstream-puljerne. Det giver mig mulighed for at skalere uden at \u00f8ge frontend-timeouts globalt.<\/p>\n\n<h2>Workers, tr\u00e5de og OS-gr\u00e6nser<\/h2>\n<p>Jeg dimensionerer ikke arbejdere, begivenheder og tr\u00e5de i henhold til \u00f8nskede v\u00e6rdier, men i henhold til <strong>lastprofil<\/strong>. Det g\u00f8r jeg ved at overv\u00e5ge aktive foresp\u00f8rgsler, inaktive arbejdere, udnyttelse af event loop og kontekstskift. Hvis tr\u00e5de er parkeret i idle-tilstand, s\u00e6nker jeg timeout eller max-idle-per-thread-gr\u00e6nserne. Hvis jeg ser 100 procent CPU hele tiden, tjekker jeg acceptk\u00f8er, IRQ-distribution og netv\u00e6rksstakken. Sm\u00e5 korrektioner af FD-gr\u00e6nser og backlogs g\u00f8r ofte en stor forskel. <strong>Effekter<\/strong>.<\/p>\n<p>Jeg planl\u00e6gger r\u00e5derummet realistisk. En 20-30 procents reserve i tr\u00e5de og FD'er giver sikkerhed for spidsbelastninger. Hvis jeg overdriver, mister jeg cacher, og spildet stiger. Hvis jeg underdriver, ender foresp\u00f8rgsler i k\u00f8 eller udl\u00f8ber. Det rigtige sk\u00e6ringspunkt mellem <strong>Kapacitet<\/strong> og effektivitet holder ventetiden lav og beskytter <strong>Stabilitet<\/strong>.<\/p>\n\n<h2>Koordiner timeouts for klienter, load balancere og firewalls<\/h2>\n<p>Jeg s\u00e6tter tidsgr\u00e6nser langs hele stien, s\u00e5 der ikke er nogen blindgyder. <strong>Forbindelser<\/strong> er oprettet. Klienter lukker ideelt set minimalt tidligere end serveren. Loadbalanceren m\u00e5 ikke afbryde kortere, ellers vil jeg se uventede nulstillinger. Jeg inkluderer NAT- og firewall-idle-v\u00e6rdier, s\u00e5 forbindelser ikke g\u00e5r tabt p\u00e5 netv\u00e6rksstien. <strong>forsvinde<\/strong>. Denne indstilling forhindrer retransmissioner og udj\u00e6vner belastningskurverne.<\/p>\n<p>Jeg holder k\u00e6den forst\u00e5elig med klare diagrammer: Klient \u2192 LB \u2192 webserver \u2192 app. Jeg dokumenterer idle timeouts, read\/write timeouts og retry-strategier for hvert link. Hvis jeg \u00e6ndrer en v\u00e6rdi, tjekker jeg naboerne. Det holder stien konsistent og giver mig reproducerbare m\u00e5leresultater. Denne disciplin sparer tid i <strong>Fejlfinding<\/strong> og \u00f8ger <strong>p\u00e5lidelighed<\/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\/03\/optimal_configuration_server_9837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sikkerhed: Beskyttelse mod langsomme loris og misbrug i tomgang<\/h2>\n<p>\u00c5bne timeouts, der er for gener\u00f8se <strong>Angreb p\u00e5 overflader<\/strong>. Jeg s\u00e6tter derfor gr\u00e6nser, der tillader legitim genbrug, men g\u00f8r det sv\u00e6rere at holde dem \u00e5bne p\u00e5 en ondsindet m\u00e5de. I nginx hj\u00e6lper header- og read_timeout, request_headers_size-gr\u00e6nser og en h\u00e5rd \u00f8vre gr\u00e6nse for keepalive_requests. I Apache bruger jeg mod_reqtimeout og begr\u00e6nser parallelle forbindelser per IP. Hastighedsgr\u00e6nser og <strong>limit_conn<\/strong> i nginx beskytter ogs\u00e5 mod oversv\u00f8mmelser af mange inaktive sockets. For langvarige endpoints adskiller jeg dedikerede pools, s\u00e5 angreb p\u00e5 streams ikke binder almindelige API-arbejdere.<\/p>\n\n<h2>S\u00e6rlige tilf\u00e6lde: Long Polling, SSE og WebSockets<\/h2>\n<p>Lange vandl\u00f8b kolliderer med korte vandl\u00f8b <strong>Timeouts<\/strong> og har brug for deres egne regler. Jeg adskiller teknisk set disse endpoints fra klassiske API- og asset-ruter. For SSE og WebSockets indstiller jeg h\u00f8jere timeouts, dedikerede worker pools og h\u00e5rde gr\u00e6nser per IP. Jeg holder forbindelsen i live med heartbeats eller ping\/pong og genkender hurtigt afbrydelser. P\u00e5 denne m\u00e5de blokerer streams ikke tr\u00e5de for regelm\u00e6ssige <strong>Korte anmodninger<\/strong>.<\/p>\n<p>Jeg begr\u00e6nser antallet af samtidige forbindelser og m\u00e5ler aktivt. Gr\u00e6nser, der er for h\u00f8je, bruger FD'er og RAM. Gr\u00e6nser, der er for stramme, afsk\u00e6rer legitime brugere. Jeg finder det rette sted med rene m\u00e5linger for \u00e5bne, inaktive, aktive og afbrudte forbindelser. Denne adskillelse sparer mig for globale <strong>Stigninger<\/strong> timeouts og beskytter den <strong>Kapacitet<\/strong>.<\/p>\n\n<h2>HTTP\/2, multiplexing og keep-alive<\/h2>\n<p>HTTP\/2 multiplexer flere str\u00f8mme via en <strong>Forbindelse<\/strong>, men forbliver afh\u00e6ngig af timeouts. Jeg holder tomgangsvinduet moderat, fordi sessioner ogs\u00e5 kan parkere under HTTP\/2. H\u00f8je keepalive_requests er mindre vigtige her, men genbrug er stadig nyttigt. Head-of-line-blokering flyttes til rammeniveau, s\u00e5 jeg forts\u00e6tter med at m\u00e5le latency pr. <strong>Str\u00f8m<\/strong>. Hvis du vil sammenligne mere detaljeret, kan du finde baggrundsinformation p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/http2-multiplexing-vs-http11-performance-baggrund-optimering\/\">HTTP\/2 multiplexing<\/a>.<\/p>\n<p>Under HTTP\/2 er jeg s\u00e6rligt opm\u00e6rksom p\u00e5 antallet af aktive streams pr. forbindelse. For mange parallelle streams kan overbelaste app-tr\u00e5de. S\u00e5 s\u00e6nker jeg gr\u00e6nserne eller \u00f8ger antallet af serverarbejdere. Det samme g\u00e6lder her: m\u00e5l, juster, m\u00e5l igen. Dette holder <strong>Svartider<\/strong> knappe og bevarede <strong>Ressourcer<\/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\/03\/dev_desk_HTTP_timeout_4783.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>TLS, genoptagelse af sessioner og HTTP\/3\/QUIC<\/h2>\n<p>TLS-h\u00e5ndtryk er dyre. Jeg bruger <strong>Genoptagelse af sessionen<\/strong> (billetter\/ID'er) og OCSP-h\u00e6ftning, s\u00e5 genforbindelser er hurtigere, hvis en forbindelse oph\u00f8rer. Under HTTP\/3 overtager QUIC transportlaget: Her er det <strong>QUIC idle timeout<\/strong> svarende til Keep-Alive, men p\u00e5 UDP-basis. Ogs\u00e5 her holder jeg vinduerne moderate og m\u00e5ler retransmissioner, da pakketab har en anden effekt end med TCP. For blandede milj\u00f8er (H1\/H2\/H3) v\u00e6lger jeg standardiserede referencev\u00e6rdier og foretager finjusteringer for hver protokol.<\/p>\n\n<h2>Overv\u00e5gning, metrikker og belastningstest<\/h2>\n<p>Jeg stoler mere p\u00e5 m\u00e5ledata end p\u00e5 mavefornemmelser og starter med klare <strong>KPI'er<\/strong>. Vigtigt er: \u00e5bne sockets, FD-udnyttelse, nye forbindelser\/s, ventetider (P50\/P90\/P99), fejlrater og retransmissioner. Jeg k\u00f8rer realistiske belastningsprofiler: Opvarmning, plateau, nedtrapning. Derefter sammenligner jeg kurver f\u00f8r og efter \u00e6ndringer i timeout. Et kig p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/webserver-koing-latenstid-handtering-af-anmodninger-serverko\/\">Serverk\u00f8<\/a> hj\u00e6lper med at fortolke ventetiderne tydeligt.<\/p>\n<p>Jeg dokumenterer hver eneste justering med et tidsstempel og m\u00e5lte v\u00e6rdier. Det giver mig mulighed for at bevare historikken og genkende sammenh\u00e6nge. Jeg tager negative effekter alvorligt og ruller dem hurtigt tilbage. Sm\u00e5, forst\u00e5elige skridt sparer en masse tid. Det, der t\u00e6ller i sidste ende, er en stabil <strong>Forsinkelse<\/strong> og lav <strong>Fejlprocent<\/strong> under belastning.<\/p>\n\n<h2>M\u00e5lemetoder og v\u00e6rkt\u00f8jer i praksis<\/h2>\n<ul>\n  <li><strong>Hurtige tests:<\/strong> Jeg bruger v\u00e6rkt\u00f8jer som wrk, ab eller vegeta til at tjekke genbrugskvoter (-H-forbindelse: keep-alive vs. close), forbindelser\/s og latency-percentiler.<\/li>\n  <li><strong>Systemvisning:<\/strong> ss\/netstat viser statusser (ESTABLISHED, TIME_WAIT), lsof -p FD-forbruget, dmesg\/syslog-indikationer p\u00e5 drops.<\/li>\n  <li><strong>Metrikker for webservere:<\/strong> nginx stub_status\/VTS og Apache mod_status giver aktiv\/ledig\/ventende og anmodninger\/s. Ud fra dette kan jeg genkende inaktive toppe eller flaskehalse.<\/li>\n  <li><strong>Spor:<\/strong> Jeg bruger distribueret sporing til at overv\u00e5ge, om der opst\u00e5r ventetider ved netv\u00e6rksgr\u00e6nsen eller i appen.<\/li>\n<\/ul>\n\n<h2>Konfigurer trin for trin<\/h2>\n<p>F\u00f8rst bestemmer jeg det reelle brugsm\u00f8nster: hvor mange anmodninger pr. session, hvilke <strong>Intervaller<\/strong> mellem klik, hvor store er svarene. S\u00e5 indstiller jeg en indledende profil: timeout 10 s, keepalive_requests 200, moderat antal arbejdere. Derefter udf\u00f8rer jeg belastningstests med repr\u00e6sentative data. Jeg evaluerer antallet af nye forbindelser pr. sekund og FD-udnyttelsen. Derefter justerer jeg <strong>V\u00e6rdier<\/strong> i intervaller p\u00e5 2-3 sekunder.<\/p>\n<p>Jeg gentager cyklussen, indtil latenstiden forbliver stabil under belastning, og FD-peaks ikke n\u00e5r gr\u00e6nsen. Med tung trafik \u00f8ger jeg kun timeout, hvis jeg tydeligt kan se f\u00e6rre nye forbindelser, og der stadig er ledige workers. Ved lav udnyttelse reducerer jeg timeouten for at undg\u00e5 tomgang. I s\u00e6rlige tilf\u00e6lde som SSE indstiller jeg dedikerede serverblokke med h\u00f8jere gr\u00e6nser. Denne vej f\u00f8rer til en modstandsdygtig <strong>Indstilling<\/strong> uden sats p\u00e5 pap.<\/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\/03\/servereinstellung-performance-1987.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kubernetes, containere og automatisk skalering<\/h2>\n<p>I containermilj\u00f8er bruger jeg <strong>conntrack<\/strong>-gr\u00e6nser, pod FD-gr\u00e6nser og node-backlogs. Jeg sikrer ensartede idle timeouts mellem Ingress, service mesh\/proxy og app. Ved automatisk skalering er jeg opm\u00e6rksom p\u00e5 <strong>T\u00f8mningstider<\/strong>N\u00e5r pods afsluttes, b\u00f8r de afvise nye forbindelser via \u201eConnection: close\u201c og betjene de eksisterende p\u00e5 en ren m\u00e5de. Keep alive-v\u00e6rdier, der er for lange, forl\u00e6nger drains un\u00f8digt, mens de, der er for korte, skaber handshake-storme, n\u00e5r der skaleres ud.<\/p>\n\n<h2>Graceful shutdown og rullende implementeringer<\/h2>\n<p>Jeg planl\u00e6gger ogs\u00e5 at slukke. F\u00f8r en udrulning reducerer jeg gradvist Keep-Alive eller sender m\u00e5lrettede <strong>Forbindelse: luk<\/strong> p\u00e5 Responses, s\u00e5 klienter ikke \u00e5bner nye inaktive forbindelser. I nginx er en <strong>worker_shutdown_timeout<\/strong> til k\u00f8rende foresp\u00f8rgsler. I Apache bruger jeg graci\u00f8se mekanismer og holder \u00f8je med MaxConnectionsPerChild\/Worker, s\u00e5 genbrug finder sted automatisk over tid. Det g\u00f8r udrulningen j\u00e6vn uden at s\u00e6tte et h\u00e5rdt loft over \u00e5bne sockets.<\/p>\n\n<h2>OS-tuning: porte, timeouts, kerneparametre<\/h2>\n<ul>\n  <li><strong>kortvarige havne:<\/strong> V\u00e6lg et bredt interval for ip_local_port_range, s\u00e5 kortvarige forbindelser ikke kommer til at mangle noget.<\/li>\n  <li><strong>TIME_WAIT:<\/strong> Jeg holder \u00f8je med TW-peaks. Moderne stakke h\u00e5ndterer dette godt; jeg undg\u00e5r tvivlsomme tweaks (tw_recycle).<\/li>\n  <li><strong>tcp_keepalive_time:<\/strong> Jeg forveksler det ikke med HTTP Keep-Alive. Det er en kernemekanisme til at genkende d\u00f8de peers - nyttig bag NAT, men ikke en erstatning for HTTP idle window.<\/li>\n  <li><strong>Eftersl\u00e6b og buffere:<\/strong> dimension somaxconn, tcp_max_syn_backlog og rmem\/wmem fornuftigt for ikke at drosle ned under belastning.<\/li>\n<\/ul>\n\n<h2>Tjekliste til fejlfinding<\/h2>\n<ul>\n  <li><strong>Mange nye forbindelser\/s p\u00e5 trods af keep-alive:<\/strong> Timeout for kort eller klienter\/LB afbrudt tidligere.<\/li>\n  <li><strong>H\u00f8je tomgangstal og fuld FD:<\/strong> Timeout er for lang, eller worker pools er for store til trafikm\u00f8nsteret.<\/li>\n  <li><strong>RST\/Timeout-fejl ved l\u00e6ngere sessioner:<\/strong> NAT\/firewall idle for kort i stien, asymmetri mellem links.<\/li>\n  <li><strong>Lange ventetider (P99):<\/strong> Tjek send\/l\u00e6s timeouts, langsomme klienter eller overfyldte backlogs.<\/li>\n  <li><strong>Backends overbelastet trods lav kantbelastning:<\/strong> Opstr\u00f8msburet mangler eller er for lille.<\/li>\n<\/ul>\n\n<h2>Praksisprofiler og startv\u00e6rdier<\/h2>\n<ul>\n  <li><strong>API-f\u00f8rst (korte opkald):<\/strong> Keep-Alive 5-10 s, keepalive_requests 200-300, tight header\/read timeouts.<\/li>\n  <li><strong>E-handel (blandet):<\/strong> 8-12 s, 200-400, lidt mere gener\u00f8st for produktbilleder og caching-hits.<\/li>\n  <li><strong>Assets\/CDN-lignende (mange sm\u00e5 filer):<\/strong> 10-15 s, 300-500, st\u00e6rke opstr\u00f8ms pools og h\u00f8je FD-gr\u00e6nser.<\/li>\n  <li><strong>Intranet\/lav belastning:<\/strong> 5-8 s, 100-200, s\u00e5 tomgang ikke dominerer.<\/li>\n<\/ul>\n\n<h2>Kort opsummeret<\/h2>\n<p>Jeg indstiller HTTP keep-alive timeout, s\u00e5 forbindelser genbruges uden at blokere tr\u00e5de. I praksis giver 5-15 sekunder og 100-500 foresp\u00f8rgsler pr. forbindelse meget gode resultater. Jeg koordinerer timeouts for klienter, load balancere og firewalls, adskiller langvarige forbindelser som WebSockets og regulerer OS-gr\u00e6nser. Med ren overv\u00e5gning, realistiske belastningstests og sm\u00e5 skridt opn\u00e5r jeg lave <strong>Forsinkelser<\/strong> og h\u00f8j <strong>Gennemstr\u00f8mning<\/strong>. De, der opretholder denne disciplin, f\u00e5r m\u00e5lbar ydeevne ud af eksisterende hardware.<\/p>","protected":false},"excerpt":{"rendered":"<p>Optimerede HTTP keep-alive timeout-indstillinger for bedre serverydelse. Praktisk guide til tuning af webservere og styring af forbindelser.<\/p>","protected":false},"author":1,"featured_media":18049,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-18056","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":"848","_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":"HTTP Keep-Alive Timeout","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":"18049","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/18056","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=18056"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/18056\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/18049"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=18056"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=18056"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=18056"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}