{"id":21159,"date":"2026-08-30T08:32:07","date_gmt":"2026-08-30T06:32:07","guid":{"rendered":"https:\/\/webhosting.de\/apache-keepalive-timeout-optimal-einstellen-performance-focus\/"},"modified":"2026-08-30T08:32:07","modified_gmt":"2026-08-30T06:32:07","slug":"optimal-indstilling-af-apache-keepalive-timeout-med-fokus-pa-ydeevne","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/apache-keepalive-timeout-optimal-einstellen-performance-focus\/","title":{"rendered":"Indstil Apache KeepAlive-timeout optimalt for maksimal ydeevne"},"content":{"rendered":"<p>Jeg indstiller <strong>apache<\/strong> Indstil keepalive-timeout s\u00e5ledes, at forbindelser genbruges effektivt uden at blokere v\u00e6rdifulde workere. Ved hj\u00e6lp af klare retningslinjer og m\u00e5lepunkter justerer jeg <strong>Timeout<\/strong> specielt udviklet til at \u00f8ge gennemstr\u00f8mningen og g\u00f8re sideindl\u00e6sningen hurtigere.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<ul>\n  <li><strong>KeepAlive<\/strong> reducerer TCP-\/TLS-overhead og mindsker forsinkelserne.<\/li>\n  <li><strong>Timeout<\/strong> bestemmer, hvor l\u00e6nge Apache venter p\u00e5 nye anmodninger.<\/li>\n  <li><strong>For kort<\/strong> koster h\u00e5ndtryk, <strong>for lang<\/strong> binder arbejdere.<\/li>\n  <li><strong>Standardv\u00e6rdier<\/strong>: 2\u20135 sek. (API\/belastning), 3\u20135 sek. (web), 5\u201315 sek. (ressourcer).<\/li>\n  <li><strong>Event-MPM<\/strong> og overv\u00e5gning sikrer reelle resultater.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/apache-server-performance-3275.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad Keep-Alive og KeepAliveTimeout g\u00f8r i Apache<\/h2>\n\n<p>HTTP Keep-Alive samler flere anmodninger fra en klient i \u00e9n enkelt TCP-forbindelse og sparer dermed <strong>CPU<\/strong> og TLS-h\u00e5ndtryk. Direktivet <strong>KeepAlive<\/strong> aktiverer denne funktion, mens KeepAliveTimeout angiver ventetiden i sekunder, indtil Apache afbryder en inaktiv forbindelse. Typiske startv\u00e6rdier er KeepAlive On, KeepAliveTimeout 5 og MaxKeepAliveRequests mellem 100 og 500, hvilket udg\u00f8r et fornuftigt kompromis. En for gener\u00f8s timeout holder processer inaktive, selvom der ikke kommer flere anmodninger. En for lav v\u00e6rdi tvinger nye forbindelser frem og \u00f8ger ventetiderne. Jeg bruger derfor et sn\u00e6vert tidsvindue, der d\u00e6kker sammenh\u00e6ngende anmodninger uden at binde arbejdsprocesser i l\u00e6ngere tid.<\/p>\n\n<h2>For kort kontra for langt: den afg\u00f8rende m\u00e5lkonflikt<\/h2>\n\n<p>En kort timeout medf\u00f8rer flere nye forbindelser pr. sidevisning og \u00f8ger dermed <strong>Overhead<\/strong>. Mange sm\u00e5 filer som billeder, CSS og JS drager klart fordel af genbrugte forbindelser, alts\u00e5 af en b\u00e5ndbredde, der ikke er for begr\u00e6nset <strong>Timeout<\/strong>. Derimod blokerer lange timeouts v\u00e6rdifulde arbejdsprocesser og kan skabe k\u00f8er ved spidsbelastninger. Det f\u00f8rer til langsomme svar eller fejlmeddelelser, selvom selve behandlingen kunne foreg\u00e5 hurtigt. Erfaringen viser, at 2\u20135 sekunder fungerer meget godt for t\u00e6tte, hurtige arbejdsbelastninger, mens 5\u201315 sekunder kun giver mening, hvis der er rigeligt med ressourcer. Alt over 60 sekunder giver n\u00e6ppe mening i produktive milj\u00f8er, fordi for mange processer forbliver inaktive.<\/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\/apache_perf_besprechung_2345.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Anbefalede retningslinjer afh\u00e6ngigt af arbejdsbyrden<\/h2>\n\n<p>Jeg baserer mig p\u00e5 klare profiler: API-servere f\u00e5r som regel 2\u20133 sekunder, fordi de kr\u00e6ver h\u00f8j gennemstr\u00f8mning og hurtig frigivelse af <strong>Arbejder<\/strong> kr\u00e6ver. Traditionelle hjemmesider med mange ressourcer fungerer godt med 3\u20135 sekunder for at samle vandfaldsforesp\u00f8rgsler p\u00e5 en fornuftig m\u00e5de. Asset-dom\u00e6ner med rigtig mange sm\u00e5 filer kan klare 5\u201310 sekunder, forudsat at der er tilstr\u00e6kkelige ressourcer til r\u00e5dighed. Hvis der er en reverse-proxy foran Apache, indstiller jeg korte timeouts p\u00e5 1\u20132 sekunder bagved, da proxyen h\u00e5ndterer klientforbindelserne <strong>administreret<\/strong>. Hvis man \u00f8nsker at dykke dybere ned i grundl\u00e6ggende emner, finder man en solid indf\u00f8ring i <a href=\"https:\/\/webhosting.de\/da\/http-keepalive-timeout-konfiguration-af-serverens-ydeevne\/\">Konfigurationsvejledning<\/a>.<\/p>\n\n<h2>Praktiske startkonfigurationer<\/h2>\n\n<p>For moderne websteder med Event-MPM fungerer en startv\u00e6rdi p\u00e5 KeepAliveTimeout p\u00e5 3 sekunder sammen med MaxKeepAliveRequests p\u00e5 300 meget <strong>effektiv<\/strong>. P\u00e5 den m\u00e5de d\u00e6kker jeg de fleste sammenh\u00e6ngende anmodninger ved et sidebes\u00f8g uden at risikere inaktivitet. Jeg starter ofte API-serveren med 2 sekunder og 200\u2013300 MaxKeepAliveRequests, hvilket reducerer ventetiderne og <strong>Gennemstr\u00f8mning<\/strong> forh\u00f8jet. Ressourcekr\u00e6vende servere med ledig kapacitet p\u00e5 CPU og RAM drager ofte fordel af en timeout p\u00e5 5\u201310 sekunder og 500\u20131000 MaxKeepAliveRequests. Statiske minimalsider drager sj\u00e6ldent fordel af Keep-Alive; her deaktiverer jeg det lejlighedsvis, hvis test viser klare fordele.<\/p>\n\n<h2>Kombiner MPM og relaterede direktiver p\u00e5 en fornuftig m\u00e5de<\/h2>\n\n<p>Event-MPM h\u00e5ndterer inaktive forbindelser s\u00e6rdeles sparsomt, hvilket betyder, at en moderat KeepAliveTimeout er mindre <strong>risikabel<\/strong> . Derudover tjekker jeg den globale timeout-direktiv, som b\u00f8r v\u00e6re betydeligt h\u00f8jere end KeepAliveTimeout, ofte p\u00e5 30\u201360 sekunder. MaxKeepAliveRequests indstiller jeg, afh\u00e6ngigt af m\u00f8nsteret, til mellem 200 og 500, og for rene asset-hosts ogs\u00e5 h\u00f8jere, forudsat at <strong>Risici for angreb<\/strong> holde \u00f8je med. P\u00e5 den m\u00e5de forbliver Apache hurtig, selv n\u00e5r klienter henter mange sm\u00e5 filer. Forkerte indstillinger, der enten skaber un\u00f8dvendige handshakes eller binder arbejdsprocesser for l\u00e6nge, er kritiske. Den bedste kombination opn\u00e5s gennem test, observation og trinvise justeringer.<\/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\/apache-keepalive-optimization-5843.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Trin-for-trin-optimering med overv\u00e5gning<\/h2>\n\n<p>Jeg starter med en trafikanalyse: Antallet af assets, typiske indl\u00e6sningstider, burst-adf\u00e6rd og pauser mellem anmodninger er afg\u00f8rende for <strong>Timeout<\/strong> afg\u00f8rende. Derefter indstiller jeg en startv\u00e6rdi: 3 sekunder for blandede arbejdsbelastninger, 2 sekunder for API\u2019er, 5 sekunder for asset-dom\u00e6ner. Derefter overv\u00e5ger jeg \u00e5bne forbindelser, RAM, CPU, svartider og fejlkoder. Hvis mange arbejdsprocesser optages af inaktive forbindelser, reducerer jeg <strong>ventetid<\/strong>. Hvis der derimod opst\u00e5r flere nye forbindelser, og ventetiderne stiger, \u00f8ger jeg tiden i sm\u00e5 trin p\u00e5 1\u20132 sekunder. Den korte artikel giver en struktureret fremgangsm\u00e5de <a href=\"https:\/\/webhosting.de\/da\/guide-til-optimering-af-webserverens-ydeevne\/\">Vejledning i ydeevneoptimering<\/a>.<\/p>\n\n<h2>At l\u00e6se og fortolke n\u00f8gletal korrekt<\/h2>\n\n<p>Et kig p\u00e5 server-status, adgangslogfiler og vandfaldsdiagrammer viser, hvordan anmodningerne falder sammen tidsm\u00e6ssigt, og hvor l\u00e6nge forbindelserne varer <strong>st\u00e5<\/strong>. Et h\u00f8jt antal nye TCP-\/TLS-opkoblinger tyder p\u00e5, at KeepAliveTimeout er for kort. Mange inaktive arbejdsprocesser med inaktive forbindelser tyder p\u00e5 for lange ventetider. Jeg sammenligner disse fund med brugeroplevelsen: Indl\u00e6ses siderne m\u00e6rkbart hurtigere, eller stiger antallet af afbrud? P\u00e5 stigende 503\/504-fejl reagerer jeg med kortere inaktivitetstider eller flere <strong>Arbejder<\/strong>. S\u00e5 n\u00e6rmer jeg mig trin for trin det optimale punkt.<\/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\/apache_timeout_optimierung_9876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Arbejdsbelastningsprofiler: Websted, API, proxy<\/h2>\n\n<p>P\u00e5 hjemmesider med mange ressourcer samler jeg flere anmodninger i hurtig r\u00e6kkef\u00f8lge p\u00e5 en <strong>Forbindelse<\/strong>, derfor fungerer 3\u20135 sekunder godt. API\u2019er har gavn af knap 2\u20133 sekunder, da hurtig frigivelse af ressourcer er afg\u00f8rende her. Med en forudg\u00e5ende reverse-proxy indstiller jeg Apache til korte backend-faser, ofte 1\u20132 sekunder, fordi proxyen <strong>Kunde<\/strong>-Persistens tager over. Statiske sider med f\u00e5 filer vinder n\u00e6sten intet p\u00e5 Keep-Alive; jeg tester tilstandene \u00bbtil\u00ab og \u00bbfra\u00ab og m\u00e5ler objektivt. Det er profilen, der afg\u00f8r den optimale v\u00e6rdi, ikke \u00f8nsket\u00e6nkning. Netop derfor tjekker jeg regelm\u00e6ssigt, om trafikken har \u00e6ndret sig.<\/p>\n\n<h2>Tabel: Anbefalinger vedr\u00f8rende timeout og konsekvenser<\/h2>\n\n<p>I den f\u00f8lgende oversigt knyttes typiske anvendelsesscenarier til konkrete v\u00e6rdier, og der n\u00e6vnes centrale effekter samt risici. Jeg bruger den som <strong>Udgangspunkt<\/strong> og juster derefter i forhold til de faktiske m\u00e5lev\u00e6rdier for at finjustere den endelige v\u00e6rdi. Bem\u00e6rk: Intervallet angiver fornuftige rammer, ikke en fast gr\u00e6nse. \u00c6ndringer b\u00f8r foretages i sm\u00e5 trin, s\u00e5 jeg tydeligt kan se systemets reaktion. Kun p\u00e5 den m\u00e5de forbliver effekterne p\u00e5viselige og <strong>forst\u00e5elig<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Scenarie<\/th>\n      <th>KeepAliveTimeout<\/th>\n      <th>MaxKeepAliveRequests<\/th>\n      <th>Hovedvirkning<\/th>\n      <th>mulig risiko<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>API\/mikrotjeneste<\/td>\n      <td>2\u20133 sekunder<\/td>\n      <td>100-300<\/td>\n      <td>Hurtig frigivelse, h\u00f8jere gennemstr\u00f8mning<\/td>\n      <td>Flere nye forbindelser, hvis v\u00e6rdien er for lille<\/td>\n    <\/tr>\n    <tr>\n      <td>Hjemmeside med mange ressourcer<\/td>\n      <td>3\u20135 sekunder<\/td>\n      <td>300\u2013500<\/td>\n      <td>F\u00e6rre h\u00e5ndtryk, kortere indl\u00e6sningstider<\/td>\n      <td>Ved overbelastning kan der eventuelt v\u00e6re inaktive arbejdere<\/td>\n    <\/tr>\n    <tr>\n      <td>Asset-dom\u00e6ne (meget mange filer)<\/td>\n      <td>5-10 s<\/td>\n      <td>500\u20131000<\/td>\n      <td>Effektiv samling af mange anmodninger<\/td>\n      <td>L\u00e6ngere binding af forbindelser<\/td>\n    <\/tr>\n    <tr>\n      <td>Reverse-proxy foran Apache<\/td>\n      <td>1\u20132 sekunder<\/td>\n      <td>100-300<\/td>\n      <td>Hurtigt backend, proxy opretholder klientforbindelser<\/td>\n      <td>For kort ved sj\u00e6ldne burst-sekvenser<\/td>\n    <\/tr>\n    <tr>\n      <td>Statisk minimalside<\/td>\n      <td>Fra eller 1\u20132 s<\/td>\n      <td>lav<\/td>\n      <td>Maksimal gennemstr\u00f8mning pr. worker<\/td>\n      <td>Ingen fordel ved genbrug<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Jeg bruger disse v\u00e6rdier som en indledende plan og tjekker dem op mod n\u00f8gletal som f.eks. uafsluttede <strong>Forbindelser<\/strong>, ventetid og fejlprocent. Hvis tallene viser flaskehalse, justerer jeg Timeout og MaxKeepAliveRequests trin for trin. En justering uden m\u00e5linger f\u00f8rer ofte i den forkerte retning. Det er bedre at foretage sm\u00e5 \u00e6ndringer og n\u00f8je observere resultatet. P\u00e5 den m\u00e5de forbliver ydeevnen reproducerbar og <strong>harmonisk<\/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\/ApacheKeepAliveTimeout_4729.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Test af konfigurationen: V\u00e6rkt\u00f8jer og fremgangsm\u00e5de<\/h2>\n\n<p>Jeg validerer hver \u00e6ndring ved hj\u00e6lp af syntetiske belastningstests og reel trafik, s\u00e5 <strong>M\u00e5lte v\u00e6rdier<\/strong> er kan klare belastningen. V\u00e6rkt\u00f8jer som ab, wrk eller k6 viser mig gennemstr\u00f8mning og fejlfordeling under belastning. Samtidig tjekker jeg serverstatus og logfiler for at se inaktivitetstider, nye forbindelser og svartider. Efter hver \u00e6ndring venter jeg l\u00e6nge nok til, at tallene bliver signifikante. Til den praktiske r\u00e6kkef\u00f8lge bruger jeg gerne en kompakt <a href=\"https:\/\/webhosting.de\/da\/http-keep-alive-tuning-serverbelastning-ydeevneoptimering-flow\/\">Optimeringsforl\u00f8b<\/a>. Denne disciplin sikrer, at jeg ikke forveksler effekter med tilf\u00e6ldigheder <strong>skal<\/strong>.<\/p>\n\n<h2>HTTP\/2 og HTTP\/3: Hvad \u00e6ndrer sig med hensyn til Keep-Alive?<\/h2>\n<p>Med HTTP\/2 samler en klient mange samtidige streams via en enkelt forbindelse. Det reducerer antallet af parallelle TCP-forbindelser markant, og betydningen af en korrekt indstillet KeepAliveTimeout forbliver u\u00e6ndret: Jeg holder forbindelsen \u00e5ben l\u00e6nge nok til, at typiske str\u00f8msekvenser (HTML, CSS, JS, skrifttyper, billeder) kan genneml\u00f8bes problemfrit uden at kr\u00e6ve nye h\u00e5ndtryk. Samtidig har jeg ikke brug for en alt for lang timeout, fordi HTTP\/2 pakker burst-faser mere effektivt ind i en session. I praksis har mine retningslinjer for web (3\u20135 s) vist sig at v\u00e6re s\u00e6rligt effektive under HTTP\/2. Nogle moduler har deres egne HTTP\/2-specifikke gr\u00e6nsev\u00e6rdier for streams eller sessioner; jeg sikrer mig, at disse ikke er i modstrid med KeepAliveTimeout. Med HTTP\/3 (QUIC) reduceres overheadet ved oprettelse af forbindelsen yderligere, men grundtanken forbliver den samme: Jeg v\u00e6lger et tidsvindue, der afspejler de typiske foresp\u00f8rgselsgrupper, uden at ressourcerne bliver overbelastet.<\/p>\n\n<h2>HTTP Keep-Alive vs. TCP-Keepalive: en klar skelnen<\/h2>\n<p>Jeg skelner strengt mellem HTTP Keep-Alive (applikationsprotokol, genbrug til efterf\u00f8lgende anmodninger) og TCP-Keepalive (operativsystemmekanisme, der opsporer inaktive forbindelser). Indstillinger som net.ipv4.tcp_keepalive_time har ingen indflydelse p\u00e5, hvor l\u00e6nge Apache venter p\u00e5 en ny HTTP-anmodning; her er udelukkende KeepAliveTimeout relevant. OS-Keepalives hj\u00e6lper med at identificere forladte sockets (f.eks. ved netv\u00e6rksafbrydelser), men er ikke et middel til at styre HTTP-adf\u00e6rd. Hvis man blander disse niveauer sammen, drager man ofte forkerte konklusioner ud fra m\u00e5lev\u00e6rdierne. Jeg unders\u00f8ger derfor hver for sig: HTTP-metrikker for genbrug og latenstider, OS-metrikker for socket-tilstande og forbindelseskvalitet.<\/p>\n\n<h2>Kapacitetsplanl\u00e6gning: At betragte arbejdskraftbudget og timeout i sammenh\u00e6ng<\/h2>\n<p>Jeg planl\u00e6gger altid KeepAliveTimeout inden for rammerne af det samlede parallelitetsbudget (MaxRequestWorkers\/ServerLimit). En enkel tankegang kan hj\u00e6lpe: Jo l\u00e6ngere tid forbindelserne venter i inaktiv tilstand, desto st\u00f8rre er andelen af bundet kapacitet, der ikke genererer gennemstr\u00f8mning. Eksempel: Ved 400 anmodninger\/sekund og en KeepAliveTimeout p\u00e5 3 s kan der i ekstreme tilf\u00e6lde opst\u00e5 op til ca. 1200 inaktive sekunder pr. sekund, fordelt p\u00e5 mange forbindelser. Event-MPM afb\u00f8der dette ved at afkoble inaktivitet, men der er stadig en \u00f8vre gr\u00e6nseeffekt. Derfor holder jeg \u00f8je med udnyttelseskurven: Hvis antallet af travle arbejdere stiger for kraftigt under belastningsspidser, forkorter jeg inaktivitetsvinduet eller \u00f8ger forsigtigt MaxRequestWorkers (under hensyntagen til RAM). M\u00e5let er, at backend-arbejdere prim\u00e6rt besk\u00e6ftiger sig med aktiv behandling, og at inaktivitetstider ikke overg\u00e5r til k\u00f8er.<\/p>\n\n<h2>Konsistent afbalancering af timeouts i stakken<\/h2>\n<p>Ud over KeepAliveTimeout tjekker jeg altid de relaterede indstillinger: Den globale timeout-direktiv definerer faste \u00f8vre gr\u00e6nser for I\/O-operationer og b\u00f8r ligge betydeligt over Keep-Alive-v\u00e6rdien. Ved proxy-ops\u00e6tninger tilpasser jeg ProxyTimeout samt specifikke timeout-\/connectiontimeout-indstillinger for hvert backend, s\u00e5 Apache ikke afbryder for tidligt eller holder forbindelsen \u00e5ben for l\u00e6nge. Mod Slowloris-lignende m\u00f8nstre hj\u00e6lper en defensiv RequestReadTimeout-konfiguration, uden at legitime langsomme klienter straffes un\u00f8digt. I HTTP\/2-milj\u00f8er er jeg opm\u00e6rksom p\u00e5 stream- eller session-relaterede gr\u00e6nser, som reelt kan s\u00e6tte en \u00f8vre gr\u00e6nse for Keep-Alive-vinduet. Mit princip: Korte inaktivitetsvinduer til genbrug, mere gener\u00f8se, men fornuftige \u00f8vre gr\u00e6nser for reelle behandlingsprocesser \u2013 og klare sikkerhedsforanstaltninger mod misbrug.<\/p>\n\n<h2>En realistisk vurdering af TLS-omkostningerne<\/h2>\n<p>Selv med moderne kryptografi er et nyt TLS-handshake stadig mere ressourcekr\u00e6vende end en genbrug. Session-Resumption og TLS 1.3 reducerer ressourceforbruget m\u00e6rkbart, men eliminerer det ikke. Is\u00e6r ved CPU-intensive arbejdsbelastninger eller p\u00e5 mindre instanser m\u00e6rker jeg hver eneste un\u00f8dvendig h\u00e5ndtryk. Derfor betaler det sig is\u00e6r at indstille en kort, men ikke for kort KeepAliveTimeout: Jeg sparer h\u00e5ndtryk i de t\u00e6tte sekvenser ved et sidebes\u00f8g uden at holde forbindelserne inaktive i flere minutter. Mit fokus ligger p\u00e5 de f\u00f8rste sekunder efter den indledende HTML: Det er netop d\u00e9r, at den st\u00f8rste fordel ved genbrug opst\u00e5r, fordi de fleste efterf\u00f8lgende ressourcer ankommer i hurtig r\u00e6kkef\u00f8lge.<\/p>\n\n<h2>Mobilnet, \u201elange pauser\u201c og beskyttelse mod misbrug<\/h2>\n<p>I mobil- og langdistance-netv\u00e6rk svinger RTT og pakketab mere. Alt for korte timeouts kan her udl\u00f8ses tidligere, hvis klienter oplever korte afbrydelser. Jeg vurderer derfor den reelle brugerprofil: En stor andel af mobiltrafik retf\u00e6rdigg\u00f8r ofte den \u00f8vre gr\u00e6nse af mine retningslinjer for web (4\u20135 s), mens rene datacenter-til-datacenter-API'er fungerer fremragende med 2 s. Samtidig sikrer jeg mig mod misbrug: En moderat restriktiv RequestReadTimeout-strategi og begr\u00e6nsninger for samtidige forbindelser pr. IP-adresse forhindrer, at f\u00e5 klienter med mange inaktive forbindelser bremser systemet. Hvor der er en reverse-proxy foran, overlader jeg til den at h\u00e5ndtere ustabile netv\u00e6rk og holder backend'en stram.<\/p>\n\n<h2>Apache, PHP-FPM og upstreams i harmoni<\/h2>\n<p>I PHP-stacks tjekker jeg, om der er overensstemmelse mellem MaxRequestWorkers (Apache) og pm.max_children (PHP-FPM). Hvis KeepAliveTimeout er for lang, kan frontend-forbindelser \u201eparkere\u201c workers, mens anmodninger i backend venter p\u00e5 ledige PHP-slots \u2013 hvilket typisk er \u00e5rsagen til pludselige stigninger i latenstiden. Jeg minimerer denne risiko ved at holde inaktivitetsvinduet ret kort og dimensionere flaskehalsen efter det langsomste led (ofte PHP-FPM eller databasen). Bag en reverse-proxy (f.eks. CDN, Edge eller intern L7-proxy) forkorter jeg bevidst Apache-backend-vinduet, da proxyen opretholder persistente sessioner over for klienten, og origin kun er n\u00f8dvendig til den egentlige behandling.<\/p>\n\n<h2>Analysevejledning til komplicerede sager<\/h2>\n<p>N\u00e5r \u00e5rsagerne til problemerne er uklare, arbejder jeg mig systematisk fra yderkanten og indad: F\u00f8rst brugerperspektivet (indl\u00e6sningstider, vandfaldsdiagrammer), derefter Edge\/Proxy, s\u00e5 Apache (serverstatus, scoreboard) og til sidst applikationen og databasen. En p\u00e5faldende h\u00f8j andel af nye forbindelser h\u00e6nger oftest sammen med for korte KeepAlive-timeouts eller med indholdsm\u00f8nstre, der udl\u00f8ser mange korte hentninger. Omvendt tyder mange inaktive forbindelser ved samtidig h\u00f8j belastning af backend p\u00e5 for lange inaktivitetsvinduer eller for f\u00e5 arbejdsprocesser. Jeg isolerer \u00e6ndringer, tester kun \u00e9n indstilling ad gangen og lader m\u00e5lingen k\u00f8re l\u00e6nge nok til, at spidsbelastninger og baggrundsbelastning er repr\u00e6sentative. P\u00e5 den m\u00e5de kan selv sv\u00e6rt overskuelige interaktioner mellem timeouts, cacher og backends p\u00e5lideligt udredes.<\/p>\n\n<h2>\u00d8konomisk perspektiv: Omkostninger og fordele i hverdagen<\/h2>\n<p>Hvert sekund KeepAliveTimeout \u201ekoster\u201c potentielt proces- og hukommelsesressourcer, men \u201esparer\u201c TCP-\/TLS-overhead og reducerer latenstiden. Jeg betragter det som en investeringsbeslutning: For API\u2019er v\u00e6lger jeg en ret tilbageholdende tilgang, s\u00e5 gennemstr\u00f8mningen forbliver h\u00f8j i spidsbelastninger. For klassiske hjemmesider investerer jeg et lille idle-budget for at opn\u00e5 m\u00e5lbart hurtigere sideindl\u00e6sning. For asset-dom\u00e6ner \u00f8ger jeg kun dette budget, hvis overv\u00e5gning og reserver klart taler for det. Denne n\u00f8gterne afvejning forhindrer overoptimering i den forkerte retning \u2013 og sikrer, at forbedringerne er reproducerbare, i stedet for blot at skinne i benchmarks.<\/p>\n\n<h2>Oversigt over WordPress- og hostingmilj\u00f8er<\/h2>\n\n<p>WordPress-stacks kombinerer caching, dynamiske PHP-anmodninger og mange <strong>Aktiver<\/strong>, derfor er et timeout-interval p\u00e5 3\u20135 sekunder et godt udgangspunkt. Ved h\u00f8j samtidig belastning s\u00e6nker jeg det til 2\u20133 sekunder for at frigive worker-instanser hurtigere. Hvis der desuden k\u00f8rer et CDN, \u00e6ndrer profilen sig: F\u00e6rre origin-anmodninger tillader i nogle tilf\u00e6lde lidt l\u00e6ngere v\u00e6rdier. I administrerede ops\u00e6tninger s\u00f8rger jeg for, at udbyderen anvender Event-MPM, fornuftige MaxKeepAliveRequests og passende globale timeouts. Tilbud, der tager disse finesser alvorligt, leverer m\u00e6rkbart bedre brugeroplevelser. Til mange projekter er webhoster.de velegnet, fordi her <strong>Ydelse<\/strong>-Tuning og korrekt konfiguration spiller en vigtig rolle.<\/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\/apache-keepalive-9730.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Jeg holder KeepAlive som regel aktiveret og indstiller en kort <strong>Timeout<\/strong>, s\u00e5 forbindelser genbruges p\u00e5 en fornuftig m\u00e5de. For API\u2019er bruger jeg 2\u20133 sekunder, for typiske hjemmesider 3\u20135 sekunder og for asset-dom\u00e6ner 5\u201310 sekunder, hvis der er tilstr\u00e6kkelige ressourcer. Jeg dimensionerer MaxKeepAliveRequests i overensstemmelse med m\u00f8nstret og kontrollerer regelm\u00e6ssigt effekterne. Event-MPM, rene globale timeouts og systematisk overv\u00e5gning sikrer resultatet. Sm\u00e5 justeringer, klare m\u00e5linger og konsekvent testning f\u00f8rer p\u00e5lideligt til mere <strong>Str\u00f8m<\/strong> og mindre forsinkelse. P\u00e5 den m\u00e5de opn\u00e5r jeg h\u00f8j effektivitet uden at p\u00e5virke stabiliteten og ressourceforbruget negativt.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan du indstiller Apache KeepAlive Timeout optimalt og \u00f8ger din servers ydeevne gennem m\u00e5lrettet konfiguration. Denne vejledning forklarer fokusn\u00f8gleordet \u00bbapache keepalive timeout\u00ab i detaljer.<\/p>","protected":false},"author":1,"featured_media":21152,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21159","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":"113","_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":"apache 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":"21152","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21159","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=21159"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21159\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21152"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21159"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21159"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21159"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}