Ga naar de inhoud 
Ik stel de apache Stel de keepalive-timeout zo in dat verbindingen efficiënt worden hergebruikt, zonder waardevolle workers te blokkeren. Met duidelijke richtlijnen en meetpunten pas ik de Time-out speciaal ontworpen voor een hogere doorvoer en snellere laadtijden van webpagina’s.
Centrale punten
- KeepAlive vermindert de TCP-/TLS-overhead en verlaagt de latentie.
- Time-out bepaalt hoe lang Apache op nieuwe verzoeken wacht.
- Te kort kost handdrukken, te lang koppelt workers.
- Standaardwaarden: 2–5 s (API/belasting), 3–5 s (web), 5–15 s (bestanden).
- Event-MPM en monitoring zorgen voor concrete resultaten.
Wat Keep-Alive en KeepAliveTimeout in Apache doen
HTTP Keep-Alive bundelt meerdere verzoeken van een client via één enkele TCP-verbinding en bespaart zo CPU en TLS-handshakes. De richtlijn KeepAlive schakelt deze werking in, terwijl KeepAliveTimeout de wachttijd in seconden bepaalt voordat Apache een inactieve verbinding verbreekt. Typische startwaarden zijn KeepAlive On, KeepAliveTimeout 5 en MaxKeepAliveRequests tussen 100 en 500, wat een redelijk compromis biedt. Een te ruime time-out houdt processen inactief, ook al komen er geen verdere verzoeken meer binnen. Een te lage waarde dwingt tot nieuwe verbindingen en verhoogt de latentie. Ik gebruik daarom een krap tijdsvenster dat bij elkaar horende verzoeken dekt, zonder workers lang vast te houden.
Te kort versus te lang: het cruciale doelconflict
Een korte time-out zorgt voor meer nieuwe verbindingen per paginaweergave en verhoogt daarmee Overhead. Veel kleine bestanden, zoals afbeeldingen, CSS en JS, hebben duidelijk baat bij hergebruikte verbindingen, dus bij een bandbreedte die niet te beperkt is Time-out. Lange time-outs houden daarentegen waardevolle workers bezet en kunnen bij pieken in de belasting wachtrijen veroorzaken. Dit leidt tot trage reacties of foutmeldingen, hoewel de daadwerkelijke verwerking snel zou kunnen plaatsvinden. Uit ervaring blijkt dat 2–5 seconden zeer goed werken voor dichte, snelle workloads, terwijl 5–15 seconden alleen zinvol zijn bij ruime beschikbare resources. Alles boven de 60 seconden is in productieve omgevingen nauwelijks zinvol, omdat te veel processen dan inactief blijven.
Aanbevolen richtwaarden op basis van de werklast
Ik houd me aan duidelijke richtlijnen: API-servers krijgen meestal 2–3 seconden, omdat ze een hoge doorvoersnelheid en snelle vrijgave van Werknemer nodig hebben. Klassieke websites met veel assets werken goed met 3–5 seconden om watervalverzoeken op een zinvolle manier te bundelen. Asset-domeinen met zeer veel kleine bestanden kunnen 5–10 seconden aan, mits er voldoende resources beschikbaar zijn. Als er een reverse-proxy voor Apache staat, stel ik daarachter korte time-outs in van 1–2 seconden, omdat de proxy de clientverbindingen beheerd. Wie zich verder in de basisbeginselen wil verdiepen, vindt een gedegen inleiding in de Configuratiehandleiding.
Praktijkgerichte startconfiguraties
Voor moderne websites met Event-MPM werkt een startwaarde van KeepAliveTimeout van 3 seconden in combinatie met MaxKeepAliveRequests van 300 erg efficiënt. Zo vang ik de meeste bij elkaar horende verzoeken bij het laden van een pagina op, zonder het risico te lopen dat er inactieve tijd ontstaat. Ik start API-servers vaak met 2 seconden en 200–300 MaxKeepAliveRequests, wat de wachttijden verkort en Doorvoer verhoogd. Hosts met veel resources en voldoende CPU- en RAM-capaciteit hebben vaak baat bij een time-out van 5–10 seconden en 500–1000 MaxKeepAliveRequests. Statische minimale pagina’s hebben zelden baat bij Keep-Alive; hier schakel ik het af en toe uit als tests duidelijke voordelen aantonen.
MPM en aanverwante richtlijnen op een zinvolle manier combineren
De Event-MPM gaat bijzonder zuinig om met inactieve verbindingen, waardoor een gematigde KeepAliveTimeout minder riskant wordt. Daarnaast controleer ik de algemene timeout-richtlijn, die aanzienlijk hoger moet zijn dan KeepAliveTimeout, vaak tussen de 30 en 60 seconden. MaxKeepAliveRequests stel ik, afhankelijk van het patroon, in tussen 200 en 500, en bij pure asset-hosts zelfs hoger, mits Risico's op aanvallen in de gaten houden. Zo blijft Apache vlot werken, zelfs als clients veel kleine bestanden ophalen. Kritisch zijn verkeerde instellingen die ofwel onnodige handshakes veroorzaken, ofwel workers te lang vastleggen. De beste combinatie ontstaat door testen, observeren en stapsgewijze aanpassingen.
Stap-voor-stap-optimalisatie met monitoring
Ik begin met een verkeersanalyse: het aantal assets, de gebruikelijke laadtijden, het burst-gedrag en de pauzes tussen verzoeken zijn voor de Time-out cruciaal. Vervolgens stel ik een startwaarde in: 3 seconden voor gemengde workloads, 2 seconden voor API’s, 5 seconden voor asset-domeinen. Daarna houd ik de open verbindingen, het RAM-geheugen, de CPU, de responstijden en de foutcodes in de gaten. Als er veel workers worden bezet door inactieve verbindingen, verlaag ik de wachttijd. Als er daarentegen steeds meer nieuwe verbindingen ontstaan en de latentie toeneemt, verhoog ik de tijd in kleine stapjes met 1–2 seconden. Een gestructureerde aanpak wordt beschreven in de korte Handleiding voor het optimaliseren van de prestaties.
Metrics lezen en correct interpreteren
Een blik op de serverstatus, de toegangslogboeken en de watervaldagrammen laat zien hoe verzoeken in de tijd samenvallen en hoe lang verbindingen stand. Hoge percentages nieuwe TCP-/TLS-verbindingen duiden op een te korte KeepAliveTimeout. Veel inactieve workers met inactieve verbindingen wijzen op te lange wachttijden. Ik vergelijk deze bevindingen met de gebruikerservaring: laden pagina’s merkbaar sneller of neemt het aantal afgebroken verbindingen toe? Op een toename van 503/504-fouten reageer ik door de inactieve tijden te verkorten of door meer Werknemer. Zo kom ik stap voor stap dichter bij de sweet spot.
Workloadprofielen: website, API, proxy
Op websites met veel bestanden bundel ik meerdere verzoeken kort na elkaar op één Aansluiting, daarom is 3–5 seconden een goede tijd. API’s hebben baat bij een tijd van amper 2–3 seconden, omdat het hier aankomt op een snelle vrijgave van resources. Met een reverse-proxy ervoor stel ik Apache in op korte backend-fasen, vaak 1–2 seconden, omdat de proxy de Klant-Persistentie neemt het over. Statische pagina’s met weinig bestanden hebben nauwelijks baat bij Keep-Alive; ik schakel het in en uit en meet objectief. Het profiel bepaalt de optimale waarde, niet wat ik graag zou willen. Juist daarom controleer ik regelmatig of het verkeer is veranderd.
Tabel: Aanbevelingen en gevolgen van time-outs
In het volgende overzicht worden typische toepassingsscenario’s aan concrete waarden gekoppeld en worden de belangrijkste effecten en risico’s genoemd. Ik gebruik het als Startpunt en vergelijk dit vervolgens met werkelijke meetwaarden om de uiteindelijke waarde nauwkeurig af te stemmen. Let op: het bereik geeft zinvolle marges aan, geen vaste richtlijn. Wijzigingen moeten in kleine stapjes worden doorgevoerd, zodat ik de reactie van het systeem duidelijk kan waarnemen. Alleen zo blijven de effecten aantoonbaar en begrijpelijk.
| Scenario | KeepAliveTimeout | MaxKeepAliveRequests | belangrijkste effect | mogelijk risico |
|---|---|---|---|---|
| API/microservice | 2–3 s | 100-300 | Snelle vrijgave, hogere doorvoer | Meer nieuwe verbindingen bij een te lage waarde |
| Website met veel materiaal | 3–5 s | 300–500 | Minder handshakes, kortere laadtijden | Bij overbelasting eventueel idle worker |
| Asset-domein (zeer veel bestanden) | 5-10 s | 500–1000 | Goede bundeling van veel verzoeken | Langdurigere binding van verbindingen |
| Reverse-proxy vóór Apache | 1–2 s | 100-300 | Snelle backend, proxy onderhoudt clientverbindingen | Te kort bij zeldzame burst-reeksen |
| Statische minimale pagina | Uit of 1–2 s | laag | Maximale doorvoer per worker | Geen voordeel van hergebruik |
Ik gebruik deze waarden als een eerste routekaart en toets ze aan de hand van statistieken zoals openstaande Verbindingen, latentie en foutpercentage. Als uit de cijfers blijkt dat er knelpunten zijn, pas ik de time-out en MaxKeepAliveRequests stapsgewijs aan. Een aanpassing zonder metingen leidt vaak in de verkeerde richting. Het is beter om kleine wijzigingen door te voeren en deze nauwlettend te volgen. Zo blijft de prestatie reproduceerbaar en harmonieus.
Configuratie testen: hulpmiddelen en werkwijze
Ik valideer elke wijziging met synthetische belastingstests en echt verkeer, zodat de Gemeten waarden belastbaar zijn. Tools zoals ab, wrk of k6 geven me inzicht in de doorvoer en de foutverdeling onder belasting. Tegelijkertijd controleer ik de serverstatus en de logs om inactieve tijden, nieuwe verbindingen en responstijden te bekijken. Na elke wijziging wacht ik voldoende lang, zodat de cijfers representatief worden. Voor de praktische volgorde maak ik graag gebruik van een compacte Optimalisatieproces. Deze discipline zorgt ervoor dat ik effecten niet met toeval verwar moet.
HTTP/2 en HTTP/3: wat er verandert voor Keep-Alive
Met HTTP/2 bundelt een client veel gelijktijdige streams via één enkele verbinding. Hierdoor daalt het aantal parallelle TCP-verbindingen aanzienlijk, en blijft het belang van een goed ingestelde KeepAliveTimeout bestaan: Ik houd de verbinding lang genoeg open zodat typische reeksen streams (HTML, CSS, JS, lettertypen, afbeeldingen) soepel worden verwerkt, zonder dat er nieuwe handshakes nodig zijn. Tegelijkertijd heb ik geen extreem lange timeout nodig, omdat HTTP/2 burst-fasen efficiënter in één sessie verwerkt. In de praktijk zijn mijn webrichtwaarden (3–5 s) onder HTTP/2 bijzonder effectief gebleken. Sommige modules hebben hun eigen HTTP/2-specifieke limieten voor streams of sessies; ik zorg ervoor dat deze niet in strijd zijn met de KeepAliveTimeout. Bij HTTP/3 (QUIC) neemt de overhead bij het opbouwen van de verbinding verder af, maar het basisprincipe blijft hetzelfde: ik kies een tijdsvenster dat de typische verzoekgroepen weerspiegelt, zonder middelen overmatig vast te houden.
HTTP Keep-Alive versus TCP-Keepalive: een duidelijk onderscheid maken
Ik maak een strikt onderscheid tussen HTTP Keep-Alive (toepassingsprotocol, hergebruik voor vervolgverzoeken) en TCP-Keepalive (mechanisme van het besturingssysteem dat inactieve verbindingen opspoort). Instellingen zoals net.ipv4.tcp_keepalive_time hebben geen invloed op hoe lang Apache wacht op een nieuw HTTP-verzoek; daarvoor is uitsluitend KeepAliveTimeout relevant. OS-Keepalives helpen bij het herkennen van verlaten sockets (bijvoorbeeld bij netwerkonderbrekingen), maar zijn geen middel om HTTP-gedrag te sturen. Wie deze niveaus door elkaar haalt, trekt vaak de verkeerde conclusies uit meetwaarden. Ik controleer daarom afzonderlijk: HTTP-statistieken voor hergebruik en latentie, en OS-statistieken voor socketstatussen en verbindingskwaliteit.
Capaciteitsplanning: het worker-budget en de time-out in samenhang beschouwen
Ik plan de KeepAliveTimeout altijd binnen het kader van het totale concurrency-budget (MaxRequestWorkers/ServerLimit). Een eenvoudig denkpatroon helpt hierbij: hoe langer verbindingen in de idle-status blijven hangen, hoe groter het aandeel van de gebonden capaciteit dat geen doorvoer genereert. Voorbeeld: bij 400 verzoeken per seconde en een KeepAliveTimeout van 3 s zouden er in het extreme geval tot ~1200 inactieve seconden per seconde kunnen ontstaan, verdeeld over vele verbindingen. De Event-MPM ondervangt dit door de inactieve tijd los te koppelen, maar er blijft een plafond-effect bestaan. Daarom houd ik de belastingcurve in de gaten: als het aantal ‘busy workers’ tijdens piekbelastingen te sterk stijgt, verkort ik het idle-venster of verhoog ik voorzichtig MaxRequestWorkers (rekening houdend met het RAM-geheugen). Het doel is dat backend-workers zich voornamelijk bezighouden met actieve verwerking en dat idle-tijden niet uitmonden in wachtrijen.
Time-outs in de stack consistent in evenwicht brengen
Naast KeepAliveTimeout controleer ik altijd de bijbehorende instellingen: de globale timeout-richtlijn definieert strikte bovengrenzen voor I/O-bewerkingen en moet ruim boven de keep-alive-waarde liggen. Bij proxy-configuraties stel ik zowel ProxyTimeout als specifieke timeouts/connectiontimeout-opties per backend in, zodat Apache niet te vroeg afbreekt of te lang vasthoudt. Tegen Slowloris-achtige patronen helpt een defensieve RequestReadTimeout-configuratie, zonder legitieme trage clients onnodig te benadelen. In HTTP/2-omgevingen let ik op stream- of sessiegerelateerde limieten, die in feite een bovengrens kunnen stellen aan het keep-alive-venster. Mijn principe: korte idle-vensters voor hergebruik, ruimere maar zinvolle bovengrenzen voor echte verwerkingsprocessen – en duidelijke veiligheidsbarrières tegen misbruik.
TLS-kosten realistisch inschatten
Zelfs met moderne cryptografie blijft een nieuwe TLS-handshake duurder dan hergebruik. Session-resumption en TLS 1.3 verminderen de belasting merkbaar, maar maken er geen einde aan. Vooral bij CPU-intensieve workloads of op kleinere instances merk ik elke onnodige handshake. Daarom loont een korte, maar niet te korte KeepAliveTimeout bijzonder de moeite: ik bespaar handshakes in de strakke sequenties van een pagina-oproep, zonder verbindingen minutenlang inactief te laten staan. Mijn focus ligt op de eerste seconden na de eerste HTML: juist daar ontstaat het grootste voordeel van hergebruik, omdat de meeste volgende assets kort na elkaar binnenkomen.
Mobiele netwerken, „lange pauzes“ en bescherming tegen misbruik
In mobiele en langeafstandsnetwerken fluctueren RTT en pakketverlies sterker. Te krappe time-outs kunnen hier eerder in werking treden als clients korte vertragingen ondervinden. Daarom houd ik rekening met het daadwerkelijke gebruikersprofiel: een groot aandeel mobiele gebruikers rechtvaardigt vaak de bovengrens van mijn webrichtlijnen (4–5 s), terwijl pure API’s van datacenter naar datacenter prima functioneren met 2 s. Tegelijkertijd bescherm ik mezelf tegen misbruik: een gematigd restrictieve RequestReadTimeout-strategie en limieten voor gelijktijdige verbindingen per IP voorkomen dat een klein aantal clients met veel inactieve verbindingen het systeem vertragen. Als er een reverse-proxy aan de voorkant zit, laat ik die zorgen voor de robuustheid tegen wankele netwerken en houd ik de backend strak.
Apache, PHP-FPM en upstreams in harmonie
In PHP-stacks controleer ik de afstemming tussen MaxRequestWorkers (Apache) en pm.max_children (PHP-FPM). Als KeepAliveTimeout te lang is, kunnen frontend-verbindingen workers „parkeren“, terwijl verzoeken in de backend wachten op vrije PHP-slots – de typische oorzaak van plotselinge pieken in de latentie. Ik minimaliseer dit risico door de idle-tijd vrij kort te houden en de bottleneck af te stemmen op de traagste schakel (vaak PHP-FPM of de database). Achter een reverse-proxy (bijv. CDN, edge of interne L7-proxy) verkort ik bewust het Apache-backend-venster, omdat de proxy persistente sessies met de client onderhoudt en de origin alleen nodig is voor de daadwerkelijke verwerking.
Analysehandleiding voor lastige gevallen
Als de oorzaken onduidelijk zijn, werk ik strikt van buiten naar binnen: eerst het gebruikersperspectief (laadtijden, watervallen), vervolgens Edge/Proxy, daarna Apache (server-status, Scoreboard) en ten slotte de applicatie en de database. Opvallend hoge percentages nieuwe verbindingen hangen meestal samen met te korte KeepAlive-time-outs of met inhoudspatronen die veel korte verzoeken veroorzaken. Omgekeerd duiden veel inactieve verbindingen bij een tegelijkertijd hoge backend-belasting op te lange inactieve periodes of te weinig workers. Ik isoleer wijzigingen, test telkens slechts één instelling en laat de meting lang genoeg lopen, zodat piekfasen en achtergrondbelasting representatief zijn. Zo kunnen zelfs moeilijk te doorgronden interacties tussen time-outs, caches en backends betrouwbaar worden ontrafeld.
Economisch perspectief: kosten-baten in het dagelijks leven
Elke seconde KeepAliveTimeout „kost“ mogelijk proces- en geheugenbronnen, maar „bespaart“ TCP-/TLS-overhead en vermindert de latentie. Ik beschouw dit als een investeringsbeslissing: voor API’s kies ik voor een vrij zuinige aanpak, zodat de doorvoer tijdens piekbelastingen hoog blijft. Voor klassieke websites investeer ik een klein idle-budget om meetbaar snellere laadtijden te realiseren. Bij asset-domeinen verhoog ik dit budget alleen als monitoring en reserves daar duidelijk aanleiding toe geven. Deze nuchtere afweging voorkomt overoptimalisatie in de verkeerde richting – en zorgt ervoor dat verbeteringen reproduceerbaar zijn, in plaats van alleen in benchmarks te schitteren.
WordPress- en hostingomgevingen in één oogopslag
WordPress-stacks combineren caching, dynamische PHP-verzoeken en talrijke Activa, daarom is een timeout-bandbreedte van 3–5 seconden een goed uitgangspunt. Bij een hoge gelijktijdige belasting verlaag ik dit naar 2–3 seconden om workers sneller vrij te geven. Als er bovendien een CDN draait, verschuift het profiel: bij minder origin-verzoeken zijn soms iets langere waarden mogelijk. Bij beheerde opstellingen let ik erop dat providers Event-MPM, zinvolle MaxKeepAliveRequests en passende globale time-outs gebruiken. Aanbiedingen die deze fijne nuances serieus nemen, zorgen voor een merkbaar betere gebruikerservaring. Voor veel projecten is webhoster.de geschikt, omdat hier Prestaties-Tuning en een zorgvuldige configuratie spelen een belangrijke rol.
Kort samengevat
Ik laat KeepAlive meestal ingeschakeld en stel een korte Time-out, zodat verbindingen op een zinvolle manier worden hergebruikt. Voor API’s hanteer ik 2–3 seconden, voor standaardwebsites 3–5 seconden en voor asset-domeinen 5–10 seconden, mits er voldoende resources beschikbaar zijn. Ik stel MaxKeepAliveRequests af op het patroon en controleer regelmatig de effecten. Event-MPM, strakke globale time-outs en systematische monitoring waarborgen het resultaat. Kleine aanpassingen, duidelijke statistieken en consequent testen leiden betrouwbaar tot meer Prestaties en minder vertraging. Zo bereik ik een hoge efficiëntie zonder dat dit ten koste gaat van de stabiliteit en het verbruik van systeembronnen.
