Hoppa till innehåll 
Jag ställer in apache Ställ in keepalive-timeouten så att anslutningarna återanvänds effektivt utan att blockera värdefulla arbetare. Med tydliga riktvärden och mätpunkter justerar jag Tidsgräns speciellt utformad för högre genomströmning och snabbare sidladdning.
Centrala punkter
- KeepAlive minskar TCP-/TLS-överhead och sänker latensen.
- Tidsgräns styr hur länge Apache väntar på nya förfrågningar.
- För kort kostar handskakningar, för långt binder arbetare.
- Standardvärden: 2–5 sekunder (API/belastning), 3–5 sekunder (webb), 5–15 sekunder (resurser).
- Event-MPM och uppföljning säkerställer konkreta resultat.
Vad Keep-Alive och KeepAliveTimeout gör i Apache
HTTP Keep-Alive sammanför flera förfrågningar från en klient via en enda TCP-anslutning och sparar därmed CPU och TLS-handshakes. Direktivet KeepAlive aktiverar detta beteende, medan KeepAliveTimeout anger väntetiden i sekunder innan Apache avbryter en inaktiv anslutning. Typiska startvärden är KeepAlive On, KeepAliveTimeout 5 och MaxKeepAliveRequests mellan 100 och 500, vilket ger en rimlig kompromiss. En alltför generös timeout håller processer inaktiva även om inga ytterligare förfrågningar kommer in. Ett för lågt värde tvingar fram nya anslutningar och ökar latensen. Jag använder därför ett snävt tidsfönster som täcker sammanhängande förfrågningar utan att binda upp arbetare under lång tid.
För kort kontra för lång: den avgörande målsättningskonflikten
En kort timeout leder till fler nya anslutningar per sidvisning och ökar därmed Overhead. Många små resurser, såsom bilder, CSS och JS, har uppenbara fördelar av återanvända anslutningar, det vill säga av en anslutning som inte är alltför begränsad Tidsgräns. Å andra sidan blockerar långa timeouts värdefulla arbetare och kan orsaka köer vid belastningstoppar. Det leder till långsamma svar eller felmeddelanden, trots att själva bearbetningen skulle kunna ske snabbt. Erfarenheten visar att 2–5 sekunder fungerar mycket bra för täta, snabba arbetsbelastningar, medan 5–15 sekunder endast är meningsfullt vid rikliga resurser. Allt över 60 sekunder är knappast meningsfullt i produktiva miljöer, eftersom för många processer då förblir inaktiva.
Rekommenderade riktvärden beroende på arbetsbelastning
Jag utgår från tydliga profiler: API-servrar får oftast 2–3 sekunder, eftersom de kräver hög genomströmning och snabb godkännande av Arbetare behöver. Traditionella webbplatser med många resurser fungerar bra med 3–5 sekunder för att på ett meningsfullt sätt gruppera vattenfallsförfrågningar. Resursdomäner med väldigt många små filer klarar 5–10 sekunder, förutsatt att det finns tillräckligt med resurser. Om det finns en omvänd proxy framför Apache ställer jag in korta timeouts på 1–2 sekunder i slutet, eftersom proxyn hanterar klientanslutningarna förvaltas. Den som vill fördjupa sig i grunderna hittar en gedigen introduktion i Konfigurationsguide.
Praktiska startkonfigurationer
För moderna webbplatser med Event-MPM fungerar ett startvärde på 3 sekunder för KeepAliveTimeout tillsammans med 300 för MaxKeepAliveRequests mycket effektiv. På så sätt täcker jag de flesta sammanhängande förfrågningarna vid ett sidbesök utan att riskera att det uppstår tomgång. Jag startar ofta API-servrar med 2 sekunder och 200–300 MaxKeepAliveRequests, vilket minskar väntetiderna och Genomströmning ökad. Resurskrävande servrar med ledig kapacitet i CPU och RAM drar ofta nytta av en timeout på 5–10 sekunder och 500–1000 MaxKeepAliveRequests. Statiska minimisidor gynnas sällan av Keep-Alive; här inaktiverar jag det ibland om tester visar tydliga fördelar.
Kombinera MPM och relaterade direktiv på ett ändamålsenligt sätt
Event-MPM hanterar inaktiva anslutningar särskilt sparsamt, vilket gör att en måttlig KeepAliveTimeout ger mindre riskabel kommer att. Jag kontrollerar dessutom den globala timeout-direktiven, som bör vara betydligt högre än KeepAliveTimeout, ofta mellan 30 och 60 sekunder. MaxKeepAliveRequests ställer jag in mellan 200 och 500 beroende på mönster, och ännu högre för rena tillgångsvärdar, förutsatt att Risker för angrepp hålla koll på. På så sätt förblir Apache snabb, även när klienter hämtar många små filer. Felaktiga inställningar som antingen genererar onödiga handskakningar eller binder upp arbetare för länge är kritiska. Den bästa kombinationen uppnås genom testning, observation och stegvisa justeringar.
Optimering steg för steg med övervakning
Jag börjar med en trafikanalys: antalet tillgångar, typiska laddningstider, toppbelastningar och pauser mellan förfrågningar är avgörande för Tidsgräns avgörande. Därefter anger jag ett startvärde: 3 sekunder för blandade arbetsbelastningar, 2 sekunder för API:er, 5 sekunder för tillgångsdomäner. Därefter övervakar jag öppna anslutningar, RAM, CPU, svarstider och felkoder. Om många arbetare upptas av inaktiva anslutningar minskar jag väntetid. Om det däremot uppstår fler nya kopplingar och latensen ökar, höjer jag tiden i små steg med 1–2 sekunder. Den korta artikeln ger en strukturerad metod Guide till prestandajustering.
Att läsa och tolka nyckeltal på rätt sätt
En titt på serverstatus, åtkomstloggar och vattenfallsdiagram visar hur förfrågningarna överlappar varandra tidsmässigt och hur länge anslutningarna varar stå. Höga frekvenser av nya TCP-/TLS-uppkopplingar tyder på att KeepAliveTimeout är för kort. Många inaktiva arbetare med inaktiva anslutningar tyder på för långa väntetider. Jag jämför dessa resultat med användarupplevelsen: Laddas sidorna märkbart snabbare eller ökar antalet avbrutna anslutningar? På ökande 503/504-fel reagerar jag med kortare inaktivitetstider eller fler Arbetare. Så närmar jag mig steg för steg den perfekta punkten.
Arbetsbelastningsprofiler: Webbplats, API, proxy
På webbplatser med många resurser samlar jag flera förfrågningar i snabb följd på en Anslutning, därför fungerar 3–5 sekunder bra. API:er drar nytta av knappt 2–3 sekunder, eftersom det här är snabb frigöring av resurser som räknas. Med en uppströms omvänd proxy ställer jag in Apache på korta backend-faser, ofta 1–2 sekunder, eftersom proxyn Klient-Persistens tar över. Statiska sidor med få filer vinner knappt något på Keep-Alive; jag testar med funktionen på och av och mäter objektivt. Profilen avgör det optimala värdet, inte önsketänkande. Just därför kontrollerar jag regelbundet om trafiken har förändrats.
Tabell: Rekommendationer för timeout och konsekvenser
I följande översikt kopplas typiska användningsscenarier till konkreta värden och både huvudsakliga effekter och risker anges. Jag använder den som Startpunkt och jämför sedan med verkliga mätvärden för att finjustera det slutliga värdet. Observera: Intervallet visar lämpliga intervall, inte några fasta riktvärden. Ändringar bör göras i små steg så att jag tydligt kan se systemets reaktion. Endast på så sätt kan effekterna bevisas och begriplig.
| Scenario | KeepAliveTimeout | MaxKeepAliveRequests | Huvudsaklig effekt | möjlig risk |
|---|---|---|---|---|
| API/mikrotjänst | 2–3 sekunder | 100-300 | Snabb godkännandeprocess, högre genomströmning | Fler nya kopplingar vid för lågt värde |
| Webbplats med många resurser | 3–5 sekunder | 300–500 | Färre handskakningar, kortare laddningstider | Vid överbelastning kan det hända att arbetare går på tomgång |
| Asset-Domain (mycket många filer) | 5-10 s | 500–1000 | Effektiv samordning av många förfrågningar | Längre bindningstid för föreningar |
| Omvänd proxy framför Apache | 1–2 sekunder | 100-300 | Snabbt backend, proxyn hanterar klientanslutningarna | För kort vid sällsynta burst-sekvenser |
| Statisk minimisida | Av eller 1–2 s | låg | Maximal genomströmning per arbetare | Ingen nytta av återanvändning |
Jag använder dessa värden som en första riktlinje och granskar dem med hjälp av nyckeltal som öppna Anslutningar, latens och felprocent. Om siffrorna visar på flaskhalsar justerar jag Timeout och MaxKeepAliveRequests stegvis. En justering utan mätning leder ofta i fel riktning. Det är bättre med små ändringar och noggrann observation. På så sätt förblir prestandan reproducerbar och harmonisk.
Testa konfigurationen: Verktyg och tillvägagångssätt
Jag validerar varje ändring med syntetiska belastningstester och verklig trafik, så att Uppmätta värden är belastningsbara. Verktyg som ab, wrk eller k6 visar mig genomströmning och felfördelning under belastning. Parallellt med detta kontrollerar jag serverstatus och loggar för att se inaktivitetstider, nya anslutningar och svarstider. Efter varje ändring väntar jag tillräckligt länge för att siffrorna ska bli signifikanta. För den praktiska ordningen använder jag gärna ett kompakt Optimeringsflöde. Denna disciplin ser till att jag inte förväxlar effekter med slumpen måste.
HTTP/2 och HTTP/3: Vad som förändras för Keep-Alive
Med HTTP/2 sammanför en klient många samtidiga strömmar via en enda anslutning. Detta minskar antalet parallella TCP-anslutningar avsevärt, och vikten av en väl inställd KeepAliveTimeout kvarstår: Jag håller anslutningen öppen tillräckligt länge för att typiska strömsekvenser (HTML, CSS, JS, teckensnitt, bilder) ska kunna köras smidigt utan att nya handskakningar krävs. Samtidigt behöver jag ingen alltför lång timeout, eftersom HTTP/2 packar in burst-faser mer effektivt i en session. I praktiken har mina riktvärden för webben (3–5 s) visat sig vara särskilt effektiva med HTTP/2. Vissa moduler har egna HTTP/2-specifika gränsvärden för strömmar eller sessioner; jag ser till att dessa inte står i strid med KeepAliveTimeout. Med HTTP/3 (QUIC) minskar overheaden vid uppkoppling ytterligare, men grundtanken kvarstår: jag väljer ett tidsfönster som speglar de typiska grupperna av förfrågningar utan att resurser parkeras i onödan.
HTTP Keep-Alive kontra TCP Keep-Alive: en tydlig åtskillnad
Jag gör en tydlig åtskillnad mellan HTTP Keep-Alive (applikationsprotokoll, återanvändning för efterföljande förfrågningar) och TCP-Keepalive (en mekanism i operativsystemet som upptäcker inaktiva anslutningar). Inställningar som net.ipv4.tcp_keepalive_time påverkar inte hur länge Apache väntar på en ny HTTP-förfrågan; för detta är endast KeepAliveTimeout relevant. OS-Keepalive hjälper till att upptäcka övergivna socklar (t.ex. vid nätverksavbrott), men är inte ett sätt att styra HTTP-beteenden. Den som blandar ihop dessa nivåer drar ofta felaktiga slutsatser utifrån mätvärdena. Därför granskar jag dem separat: HTTP-mått för återanvändning och latenser, operativsystemsmått för socket-tillstånd och anslutningskvalitet.
Kapacitetsplanering: Att tänka på arbetstagarbudget och timeout tillsammans
Jag planerar alltid KeepAliveTimeout inom ramen för den totala samtidighetsbudgeten (MaxRequestWorkers/ServerLimit). Ett enkelt tankesätt kan vara till hjälp: Ju längre anslutningarna väntar i viloläge, desto större blir andelen upptagen kapacitet som inte genererar någon genomströmning. Exempel: Vid 400 förfrågningar per sekund och en KeepAliveTimeout på 3 sekunder kan det i extrema fall uppstå upp till cirka 1 200 inaktiva sekunder per sekund, fördelat på många anslutningar. Event-MPM mildrar detta genom att avkoppla inaktiviteten, men det finns ändå en takeffekt. Därför övervakar jag belastningskurvan: Om antalet upptagna arbetare ökar för kraftigt vid belastningstoppar, förkortar jag vilofönstret eller höjer försiktigt MaxRequestWorkers (med hänsyn till RAM-minnet). Målet är att backend-arbetare i första hand ska sysselsättas med aktiv bearbetning och att inaktivitetstider inte ska övergå till köer.
Balansera timeouts i stacken på ett konsekvent sätt
Förutom KeepAliveTimeout kontrollerar jag alltid de relaterade inställningarna: Den globala timeout-direktiven definierar strikta övre gränser för I/O-operationer och bör ligga betydligt över Keep-Alive-värdet. Vid proxykonfigurationer anpassar jag ProxyTimeout samt specifika timeout- och connectiontimeout-alternativ per backend, så att Apache inte avbryter för tidigt eller håller kvar anslutningen för länge. Mot Slowloris-liknande mönster hjälper en defensiv RequestReadTimeout-konfiguration, utan att onödigt straffa legitima långsamma klienter. I HTTP/2-miljöer är jag uppmärksam på ström- eller sessionsrelaterade gränser, som i praktiken kan sätta en övre gräns för keep-alive-fönstret. Min princip: korta inaktivitetsfönster för återanvändning, generösare men rimliga övre gränser för verkliga bearbetningsprocesser – och tydliga skyddsräcken mot missbruk.
Att göra en realistisk bedömning av TLS-kostnaderna
Även med modern kryptografi är en ny TLS-handskakning fortfarande mer resurskrävande än att återanvända en befintlig. Session-Resumption och TLS 1.3 minskar belastningen märkbart, men eliminerar den inte helt. Särskilt vid CPU-intensiva arbetsbelastningar eller på mindre instanser märker jag varje onödig handskakning. Därför lönar det sig särskilt med en kort, men inte för kort, KeepAliveTimeout: Jag sparar in på handskakningar i de täta sekvenserna vid ett sidbesök, utan att hålla anslutningarna inaktiva i flera minuter. Mitt fokus ligger på de första sekunderna efter den inledande HTML-koden: det är just där som återanvändningen ger störst nytta, eftersom de flesta efterföljande resurserna anländer i snabb följd.
Mobilnät, „långa pauser“ och skydd mot missbruk
I mobilnät och långdistansnät varierar RTT och paketförlust i högre grad. Alltför korta timeouts kan här utlösas tidigare om klienter drabbas av korta avbrott. Därför utvärderar jag den faktiska användarprofilen: En stor andel mobilanvändare motiverar ofta den övre gränsen för mina riktvärden för webben (4–5 s), medan rena API:er mellan datacenter fungerar utmärkt med 2 s. Samtidigt skyddar jag mig mot missbruk: En måttligt restriktiv RequestReadTimeout-strategi och begränsningar för samtidiga anslutningar per IP-adress förhindrar att ett fåtal klienter med många inaktiva anslutningar bromsar upp systemet. Om en omvänd proxy sitter i främre ledet överlåter jag till den att hantera instabila nätverk och håller backend-delen stram.
Apache, PHP-FPM och uppströms i samklang
I PHP-stacks kontrollerar jag samordningen mellan MaxRequestWorkers (Apache) och pm.max_children (PHP-FPM). Om KeepAliveTimeout är för lång kan frontend-anslutningar „parkera“ arbetare, medan förfrågningar i backend väntar på lediga PHP-slots – vilket är den vanligaste orsaken till plötsliga fördröjningar. Jag minimerar denna risk genom att hålla inaktivitetsfönstren relativt korta och dimensionera flaskhalsen efter den långsammaste länken (ofta PHP-FPM eller databasen). Bakom en omvänd proxy (t.ex. CDN, Edge eller intern L7-proxy) förkortar jag medvetet Apache-backend-fönstret, eftersom proxyn upprätthåller beständiga sessioner gentemot klienten och ursprungsservern endast behövs för den egentliga bearbetningen.
Analyshandbok för knepiga fall
Om effekterna är oklara arbetar jag strikt från utsidan och inåt: först användarperspektivet (laddningstider, vattenfall), sedan Edge/Proxy, därefter Apache (serverstatus, resultattavla) och slutligen applikationen och databasen. Onormalt höga andelar av nya anslutningar korrelerar oftast med för korta KeepAlive-timeouts eller med innehållsmönster som orsakar många korta hämtningar. Omvänt tyder många inaktiva anslutningar i kombination med hög belastning på backend på för långa inaktivitetsfönster eller för få arbetare. Jag isolerar ändringar, testar endast en inställning åt gången och låter mätningen pågå tillräckligt länge för att toppbelastningar och bakgrundsbelastning ska vara representativa. På så sätt kan även svårfångade samspel mellan timeouts, cacher och backend-system analyseras på ett tillförlitligt sätt.
Ekonomiska perspektiv: Kostnad och nytta i vardagen
Varje sekund av KeepAliveTimeout „kostar“ potentiellt process- och minnesresurser, men „sparar“ TCP-/TLS-överhead och minskar latensen. Jag ser detta som ett investeringsbeslut: För API:er väljer jag en ganska återhållsam linje, så att genomströmningen förblir hög under belastningstoppar. För klassiska webbplatser investerar jag en liten idle-budget för att uppnå mätbart snabbare sidladdningar. När det gäller tillgångsdomäner ökar jag denna budget endast om övervakning och reserver tydligt talar för det. Denna nyktra avvägning förhindrar överoptimering i fel riktning – och säkerställer att förbättringar är reproducerbara, istället för att bara glänsa i prestandatester.
Översikt över WordPress- och webbhotellsmiljöer
WordPress-Stacks kombinerar caching, dynamiska PHP-förfrågningar och många Tillgångar, därför är en timeout-intervall på 3–5 sekunder en bra utgångspunkt. Vid hög samtidig belastning sänker jag den till 2–3 sekunder för att frigöra arbetare snabbare. Om ett CDN dessutom är igång förändras profilen: färre origin-förfrågningar tillåter ibland något längre värden. I hanterade miljöer ser jag till att leverantörerna använder Event-MPM, rimliga MaxKeepAliveRequests och lämpliga globala timeouts. Lösningar som tar dessa finesser på allvar ger märkbart bättre användarupplevelser. För många projekt är webhoster.de ett lämpligt val, eftersom man här Prestanda-Tuning och korrekt konfiguration spelar en viktig roll.
Kortfattat sammanfattat
Jag brukar ha KeepAlive aktiverat och ställer in en kort Tidsgräns, så att anslutningar återanvänds på ett meningsfullt sätt. För API:er använder jag 2–3 sekunder, för vanliga webbplatser 3–5 sekunder och för resursdomäner 5–10 sekunder, förutsatt att det finns tillräckligt med resurser. Jag dimensionerar MaxKeepAliveRequests efter mönstret och kontrollerar regelbundet effekterna. Event-MPM, tydliga globala timeouts och systematisk övervakning säkerställer resultatet. Små justeringar, tydliga mätvärden och konsekvent testning leder pålitligt till mer Effekt och lägre latens. På så sätt uppnår jag hög effektivitet utan att det påverkar stabiliteten och resursförbrukningen negativt.
