Indstil Apache KeepAlive-timeout optimalt for maksimal ydeevne

Jeg indstiller apache Indstil keepalive-timeout således, at forbindelser genbruges effektivt uden at blokere værdifulde workere. Ved hjælp af klare retningslinjer og målepunkter justerer jeg Timeout specielt udviklet til at øge gennemstrømningen og gøre sideindlæsningen hurtigere.

Centrale punkter

• KeepAlive reducerer TCP-/TLS-overhead og mindsker forsinkelserne.
• Timeout bestemmer, hvor længe Apache venter på nye anmodninger.
• For kort koster håndtryk, for lang binder arbejdere.
• Standardværdier: 2–5 sek. (API/belastning), 3–5 sek. (web), 5–15 sek. (ressourcer).
• Event-MPM og overvågning sikrer reelle resultater.

Hvad Keep-Alive og KeepAliveTimeout gør i Apache

HTTP Keep-Alive samler flere anmodninger fra en klient i én enkelt TCP-forbindelse og sparer dermed CPU og TLS-håndtryk. Direktivet KeepAlive aktiverer denne funktion, mens KeepAliveTimeout angiver ventetiden i sekunder, indtil Apache afbryder en inaktiv forbindelse. Typiske startværdier er KeepAlive On, KeepAliveTimeout 5 og MaxKeepAliveRequests mellem 100 og 500, hvilket udgør et fornuftigt kompromis. En for generøs timeout holder processer inaktive, selvom der ikke kommer flere anmodninger. En for lav værdi tvinger nye forbindelser frem og øger ventetiderne. Jeg bruger derfor et snævert tidsvindue, der dækker sammenhængende anmodninger uden at binde arbejdsprocesser i længere tid.

For kort kontra for langt: den afgørende målkonflikt

En kort timeout medfører flere nye forbindelser pr. sidevisning og øger dermed Overhead. Mange små filer som billeder, CSS og JS drager klart fordel af genbrugte forbindelser, altså af en båndbredde, der ikke er for begrænset Timeout. Derimod blokerer lange timeouts værdifulde arbejdsprocesser og kan skabe køer ved spidsbelastninger. Det fører til langsomme svar eller fejlmeddelelser, selvom selve behandlingen kunne foregå hurtigt. Erfaringen viser, at 2–5 sekunder fungerer meget godt for tætte, hurtige arbejdsbelastninger, mens 5–15 sekunder kun giver mening, hvis der er rigeligt med ressourcer. Alt over 60 sekunder giver næppe mening i produktive miljøer, fordi for mange processer forbliver inaktive.

Anbefalede retningslinjer afhængigt af arbejdsbyrden

Jeg baserer mig på klare profiler: API-servere får som regel 2–3 sekunder, fordi de kræver høj gennemstrømning og hurtig frigivelse af Arbejder kræver. Traditionelle hjemmesider med mange ressourcer fungerer godt med 3–5 sekunder for at samle vandfaldsforespørgsler på en fornuftig måde. Asset-domæner med rigtig mange små filer kan klare 5–10 sekunder, forudsat at der er tilstrækkelige ressourcer til rådighed. Hvis der er en reverse-proxy foran Apache, indstiller jeg korte timeouts på 1–2 sekunder bagved, da proxyen håndterer klientforbindelserne administreret. Hvis man ønsker at dykke dybere ned i grundlæggende emner, finder man en solid indføring i Konfigurationsvejledning.

Praktiske startkonfigurationer

For moderne websteder med Event-MPM fungerer en startværdi på KeepAliveTimeout på 3 sekunder sammen med MaxKeepAliveRequests på 300 meget effektiv. På den måde dækker jeg de fleste sammenhængende anmodninger ved et sidebesøg uden at risikere inaktivitet. Jeg starter ofte API-serveren med 2 sekunder og 200–300 MaxKeepAliveRequests, hvilket reducerer ventetiderne og Gennemstrømning forhøjet. Ressourcekrævende servere med ledig kapacitet på CPU og RAM drager ofte fordel af en timeout på 5–10 sekunder og 500–1000 MaxKeepAliveRequests. Statiske minimalsider drager sjældent fordel af Keep-Alive; her deaktiverer jeg det lejlighedsvis, hvis test viser klare fordele.

Kombiner MPM og relaterede direktiver på en fornuftig måde

Event-MPM håndterer inaktive forbindelser særdeles sparsomt, hvilket betyder, at en moderat KeepAliveTimeout er mindre risikabel . Derudover tjekker jeg den globale timeout-direktiv, som bør være betydeligt højere end KeepAliveTimeout, ofte på 30–60 sekunder. MaxKeepAliveRequests indstiller jeg, afhængigt af mønsteret, til mellem 200 og 500, og for rene asset-hosts også højere, forudsat at Risici for angreb holde øje med. På den måde forbliver Apache hurtig, selv når klienter henter mange små filer. Forkerte indstillinger, der enten skaber unødvendige handshakes eller binder arbejdsprocesser for længe, er kritiske. Den bedste kombination opnås gennem test, observation og trinvise justeringer.

Trin-for-trin-optimering med overvågning

Jeg starter med en trafikanalyse: Antallet af assets, typiske indlæsningstider, burst-adfærd og pauser mellem anmodninger er afgørende for Timeout afgørende. Derefter indstiller jeg en startværdi: 3 sekunder for blandede arbejdsbelastninger, 2 sekunder for API’er, 5 sekunder for asset-domæner. Derefter overvåger jeg åbne forbindelser, RAM, CPU, svartider og fejlkoder. Hvis mange arbejdsprocesser optages af inaktive forbindelser, reducerer jeg ventetid. Hvis der derimod opstår flere nye forbindelser, og ventetiderne stiger, øger jeg tiden i små trin på 1–2 sekunder. Den korte artikel giver en struktureret fremgangsmåde Vejledning i ydeevneoptimering.

At læse og fortolke nøgletal korrekt

Et kig på server-status, adgangslogfiler og vandfaldsdiagrammer viser, hvordan anmodningerne falder sammen tidsmæssigt, og hvor længe forbindelserne varer stå. Et højt antal nye TCP-/TLS-opkoblinger tyder på, at KeepAliveTimeout er for kort. Mange inaktive arbejdsprocesser med inaktive forbindelser tyder på for lange ventetider. Jeg sammenligner disse fund med brugeroplevelsen: Indlæses siderne mærkbart hurtigere, eller stiger antallet af afbrud? På stigende 503/504-fejl reagerer jeg med kortere inaktivitetstider eller flere Arbejder. Så nærmer jeg mig trin for trin det optimale punkt.

Arbejdsbelastningsprofiler: Websted, API, proxy

På hjemmesider med mange ressourcer samler jeg flere anmodninger i hurtig rækkefølge på en Forbindelse, derfor fungerer 3–5 sekunder godt. API’er har gavn af knap 2–3 sekunder, da hurtig frigivelse af ressourcer er afgørende her. Med en forudgående reverse-proxy indstiller jeg Apache til korte backend-faser, ofte 1–2 sekunder, fordi proxyen Kunde-Persistens tager over. Statiske sider med få filer vinder næsten intet på Keep-Alive; jeg tester tilstandene »til« og »fra« og måler objektivt. Det er profilen, der afgør den optimale værdi, ikke ønsketænkning. Netop derfor tjekker jeg regelmæssigt, om trafikken har ændret sig.

Tabel: Anbefalinger vedrørende timeout og konsekvenser

I den følgende oversigt knyttes typiske anvendelsesscenarier til konkrete værdier, og der nævnes centrale effekter samt risici. Jeg bruger den som Udgangspunkt og juster derefter i forhold til de faktiske måleværdier for at finjustere den endelige værdi. Bemærk: Intervallet angiver fornuftige rammer, ikke en fast grænse. Ændringer bør foretages i små trin, så jeg tydeligt kan se systemets reaktion. Kun på den måde forbliver effekterne påviselige og forståelig.

Scenarie	KeepAliveTimeout	MaxKeepAliveRequests	Hovedvirkning	mulig risiko
API/mikrotjeneste	2–3 sekunder	100-300	Hurtig frigivelse, højere gennemstrømning	Flere nye forbindelser, hvis værdien er for lille
Hjemmeside med mange ressourcer	3–5 sekunder	300–500	Færre håndtryk, kortere indlæsningstider	Ved overbelastning kan der eventuelt være inaktive arbejdere
Asset-domæne (meget mange filer)	5-10 s	500–1000	Effektiv samling af mange anmodninger	Længere binding af forbindelser
Reverse-proxy foran Apache	1–2 sekunder	100-300	Hurtigt backend, proxy opretholder klientforbindelser	For kort ved sjældne burst-sekvenser
Statisk minimalside	Fra eller 1–2 s	lav	Maksimal gennemstrømning pr. worker	Ingen fordel ved genbrug

Jeg bruger disse værdier som en indledende plan og tjekker dem op mod nøgletal som f.eks. uafsluttede Forbindelser, ventetid og fejlprocent. Hvis tallene viser flaskehalse, justerer jeg Timeout og MaxKeepAliveRequests trin for trin. En justering uden målinger fører ofte i den forkerte retning. Det er bedre at foretage små ændringer og nøje observere resultatet. På den måde forbliver ydeevnen reproducerbar og harmonisk.

Test af konfigurationen: Værktøjer og fremgangsmåde

Jeg validerer hver ændring ved hjælp af syntetiske belastningstests og reel trafik, så Målte værdier er kan klare belastningen. Værktøjer som ab, wrk eller k6 viser mig gennemstrømning og fejlfordeling under belastning. Samtidig tjekker jeg serverstatus og logfiler for at se inaktivitetstider, nye forbindelser og svartider. Efter hver ændring venter jeg længe nok til, at tallene bliver signifikante. Til den praktiske rækkefølge bruger jeg gerne en kompakt Optimeringsforløb. Denne disciplin sikrer, at jeg ikke forveksler effekter med tilfældigheder skal.

HTTP/2 og HTTP/3: Hvad ændrer sig med hensyn til Keep-Alive?

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ændret: Jeg holder forbindelsen åben længe nok til, at typiske strømsekvenser (HTML, CSS, JS, skrifttyper, billeder) kan gennemløbes problemfrit uden at kræve nye håndtryk. 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–5 s) vist sig at være særligt effektive under HTTP/2. Nogle moduler har deres egne HTTP/2-specifikke grænseværdier 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ælger et tidsvindue, der afspejler de typiske forespørgselsgrupper, uden at ressourcerne bliver overbelastet.

HTTP Keep-Alive vs. TCP-Keepalive: en klar skelnen

Jeg skelner strengt mellem HTTP Keep-Alive (applikationsprotokol, genbrug til efterfølgende anmodninger) og TCP-Keepalive (operativsystemmekanisme, der opsporer inaktive forbindelser). Indstillinger som net.ipv4.tcp_keepalive_time har ingen indflydelse på, hvor længe Apache venter på en ny HTTP-anmodning; her er udelukkende KeepAliveTimeout relevant. OS-Keepalives hjælper med at identificere forladte sockets (f.eks. ved netværksafbrydelser), men er ikke et middel til at styre HTTP-adfærd. Hvis man blander disse niveauer sammen, drager man ofte forkerte konklusioner ud fra måleværdierne. Jeg undersøger derfor hver for sig: HTTP-metrikker for genbrug og latenstider, OS-metrikker for socket-tilstande og forbindelseskvalitet.

Kapacitetsplanlægning: At betragte arbejdskraftbudget og timeout i sammenhæng

Jeg planlægger altid KeepAliveTimeout inden for rammerne af det samlede parallelitetsbudget (MaxRequestWorkers/ServerLimit). En enkel tankegang kan hjælpe: Jo længere tid forbindelserne venter i inaktiv tilstand, desto større er andelen af bundet kapacitet, der ikke genererer gennemstrømning. Eksempel: Ved 400 anmodninger/sekund og en KeepAliveTimeout på 3 s kan der i ekstreme tilfælde opstå op til ca. 1200 inaktive sekunder pr. sekund, fordelt på mange forbindelser. Event-MPM afbøder dette ved at afkoble inaktivitet, men der er stadig en øvre grænseeffekt. Derfor holder jeg øje med udnyttelseskurven: Hvis antallet af travle arbejdere stiger for kraftigt under belastningsspidser, forkorter jeg inaktivitetsvinduet eller øger forsigtigt MaxRequestWorkers (under hensyntagen til RAM). Målet er, at backend-arbejdere primært beskæftiger sig med aktiv behandling, og at inaktivitetstider ikke overgår til køer.

Konsistent afbalancering af timeouts i stakken

Ud over KeepAliveTimeout tjekker jeg altid de relaterede indstillinger: Den globale timeout-direktiv definerer faste øvre grænser for I/O-operationer og bør ligge betydeligt over Keep-Alive-værdien. Ved proxy-opsætninger tilpasser jeg ProxyTimeout samt specifikke timeout-/connectiontimeout-indstillinger for hvert backend, så Apache ikke afbryder for tidligt eller holder forbindelsen åben for længe. Mod Slowloris-lignende mønstre hjælper en defensiv RequestReadTimeout-konfiguration, uden at legitime langsomme klienter straffes unødigt. I HTTP/2-miljøer er jeg opmærksom på stream- eller session-relaterede grænser, som reelt kan sætte en øvre grænse for Keep-Alive-vinduet. Mit princip: Korte inaktivitetsvinduer til genbrug, mere generøse, men fornuftige øvre grænser for reelle behandlingsprocesser – og klare sikkerhedsforanstaltninger mod misbrug.

En realistisk vurdering af TLS-omkostningerne

Selv med moderne kryptografi er et nyt TLS-handshake stadig mere ressourcekrævende end en genbrug. Session-Resumption og TLS 1.3 reducerer ressourceforbruget mærkbart, men eliminerer det ikke. Især ved CPU-intensive arbejdsbelastninger eller på mindre instanser mærker jeg hver eneste unødvendig håndtryk. Derfor betaler det sig især at indstille en kort, men ikke for kort KeepAliveTimeout: Jeg sparer håndtryk i de tætte sekvenser ved et sidebesøg uden at holde forbindelserne inaktive i flere minutter. Mit fokus ligger på de første sekunder efter den indledende HTML: Det er netop dér, at den største fordel ved genbrug opstår, fordi de fleste efterfølgende ressourcer ankommer i hurtig rækkefølge.

Mobilnet, „lange pauser“ og beskyttelse mod misbrug

I mobil- og langdistance-netværk svinger RTT og pakketab mere. Alt for korte timeouts kan her udløses tidligere, hvis klienter oplever korte afbrydelser. Jeg vurderer derfor den reelle brugerprofil: En stor andel af mobiltrafik retfærdiggør ofte den øvre grænse af mine retningslinjer for web (4–5 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ænsninger for samtidige forbindelser pr. IP-adresse forhindrer, at få klienter med mange inaktive forbindelser bremser systemet. Hvor der er en reverse-proxy foran, overlader jeg til den at håndtere ustabile netværk og holder backend'en stram.

Apache, PHP-FPM og upstreams i harmoni

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 „parkere“ workers, mens anmodninger i backend venter på ledige PHP-slots – hvilket typisk er årsagen 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ødvendig til den egentlige behandling.

Analysevejledning til komplicerede sager

Når årsagerne til problemerne er uklare, arbejder jeg mig systematisk fra yderkanten og indad: Først brugerperspektivet (indlæsningstider, vandfaldsdiagrammer), derefter Edge/Proxy, så Apache (serverstatus, scoreboard) og til sidst applikationen og databasen. En påfaldende høj andel af nye forbindelser hænger oftest sammen med for korte KeepAlive-timeouts eller med indholdsmønstre, der udløser mange korte hentninger. Omvendt tyder mange inaktive forbindelser ved samtidig høj belastning af backend på for lange inaktivitetsvinduer eller for få arbejdsprocesser. Jeg isolerer ændringer, tester kun én indstilling ad gangen og lader målingen køre længe nok til, at spidsbelastninger og baggrundsbelastning er repræsentative. På den måde kan selv svært overskuelige interaktioner mellem timeouts, cacher og backends pålideligt udredes.

Økonomisk perspektiv: Omkostninger og fordele i hverdagen

Hvert sekund KeepAliveTimeout „koster“ potentielt proces- og hukommelsesressourcer, men „sparer“ TCP-/TLS-overhead og reducerer latenstiden. Jeg betragter det som en investeringsbeslutning: For API’er vælger jeg en ret tilbageholdende tilgang, så gennemstrømningen forbliver høj i spidsbelastninger. For klassiske hjemmesider investerer jeg et lille idle-budget for at opnå målbart hurtigere sideindlæsning. For asset-domæner øger jeg kun dette budget, hvis overvågning og reserver klart taler for det. Denne nøgterne afvejning forhindrer overoptimering i den forkerte retning – og sikrer, at forbedringerne er reproducerbare, i stedet for blot at skinne i benchmarks.

Oversigt over WordPress- og hostingmiljøer

WordPress-stacks kombinerer caching, dynamiske PHP-anmodninger og mange Aktiver, derfor er et timeout-interval på 3–5 sekunder et godt udgangspunkt. Ved høj samtidig belastning sænker jeg det til 2–3 sekunder for at frigive worker-instanser hurtigere. Hvis der desuden kører et CDN, ændrer profilen sig: Færre origin-anmodninger tillader i nogle tilfælde lidt længere værdier. I administrerede opsætninger sørger jeg for, at udbyderen anvender Event-MPM, fornuftige MaxKeepAliveRequests og passende globale timeouts. Tilbud, der tager disse finesser alvorligt, leverer mærkbart bedre brugeroplevelser. Til mange projekter er webhoster.de velegnet, fordi her Ydelse-Tuning og korrekt konfiguration spiller en vigtig rolle.

Kort opsummeret

Jeg holder KeepAlive som regel aktiveret og indstiller en kort Timeout, så forbindelser genbruges på en fornuftig måde. For API’er bruger jeg 2–3 sekunder, for typiske hjemmesider 3–5 sekunder og for asset-domæner 5–10 sekunder, hvis der er tilstrækkelige ressourcer. Jeg dimensionerer MaxKeepAliveRequests i overensstemmelse med mønstret og kontrollerer regelmæssigt effekterne. Event-MPM, rene globale timeouts og systematisk overvågning sikrer resultatet. Små justeringer, klare målinger og konsekvent testning fører pålideligt til mere Strøm og mindre forsinkelse. På den måde opnår jeg høj effektivitet uden at påvirke stabiliteten og ressourceforbruget negativt.