{"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":"apache-keepalive-timeout-optimaal-instellen-focus-op-prestaties","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/apache-keepalive-timeout-optimal-einstellen-performance-focus\/","title":{"rendered":"De Apache KeepAlive-time-out optimaal instellen voor maximale prestaties"},"content":{"rendered":"<p>Ik stel de <strong>apache<\/strong> Stel de keepalive-timeout zo in dat verbindingen effici\u00ebnt worden hergebruikt, zonder waardevolle workers te blokkeren. Met duidelijke richtlijnen en meetpunten pas ik de <strong>Time-out<\/strong> speciaal ontworpen voor een hogere doorvoer en snellere laadtijden van webpagina\u2019s.<\/p>\n\n<h2>Centrale punten<\/h2>\n<ul>\n  <li><strong>KeepAlive<\/strong> vermindert de TCP-\/TLS-overhead en verlaagt de latentie.<\/li>\n  <li><strong>Time-out<\/strong> bepaalt hoe lang Apache op nieuwe verzoeken wacht.<\/li>\n  <li><strong>Te kort<\/strong> kost handdrukken, <strong>te lang<\/strong> koppelt workers.<\/li>\n  <li><strong>Standaardwaarden<\/strong>: 2\u20135 s (API\/belasting), 3\u20135 s (web), 5\u201315 s (bestanden).<\/li>\n  <li><strong>Event-MPM<\/strong> en monitoring zorgen voor concrete resultaten.<\/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>Wat Keep-Alive en KeepAliveTimeout in Apache doen<\/h2>\n\n<p>HTTP Keep-Alive bundelt meerdere verzoeken van een client via \u00e9\u00e9n enkele TCP-verbinding en bespaart zo <strong>CPU<\/strong> en TLS-handshakes. De richtlijn <strong>KeepAlive<\/strong> 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.<\/p>\n\n<h2>Te kort versus te lang: het cruciale doelconflict<\/h2>\n\n<p>Een korte time-out zorgt voor meer nieuwe verbindingen per paginaweergave en verhoogt daarmee <strong>Overhead<\/strong>. Veel kleine bestanden, zoals afbeeldingen, CSS en JS, hebben duidelijk baat bij hergebruikte verbindingen, dus bij een bandbreedte die niet te beperkt is <strong>Time-out<\/strong>. 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\u20135 seconden zeer goed werken voor dichte, snelle workloads, terwijl 5\u201315 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.<\/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>Aanbevolen richtwaarden op basis van de werklast<\/h2>\n\n<p>Ik houd me aan duidelijke richtlijnen: API-servers krijgen meestal 2\u20133 seconden, omdat ze een hoge doorvoersnelheid en snelle vrijgave van <strong>Werknemer<\/strong> nodig hebben. Klassieke websites met veel assets werken goed met 3\u20135 seconden om watervalverzoeken op een zinvolle manier te bundelen. Asset-domeinen met zeer veel kleine bestanden kunnen 5\u201310 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\u20132 seconden, omdat de proxy de clientverbindingen <strong>beheerd<\/strong>. Wie zich verder in de basisbeginselen wil verdiepen, vindt een gedegen inleiding in de <a href=\"https:\/\/webhosting.de\/nl\/http-keepalive-timeout-serverprestaties-configuratie\/\">Configuratiehandleiding<\/a>.<\/p>\n\n<h2>Praktijkgerichte startconfiguraties<\/h2>\n\n<p>Voor moderne websites met Event-MPM werkt een startwaarde van KeepAliveTimeout van 3 seconden in combinatie met MaxKeepAliveRequests van 300 erg <strong>effici\u00ebnt<\/strong>. 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\u2013300 MaxKeepAliveRequests, wat de wachttijden verkort en <strong>Doorvoer<\/strong> verhoogd. Hosts met veel resources en voldoende CPU- en RAM-capaciteit hebben vaak baat bij een time-out van 5\u201310 seconden en 500\u20131000 MaxKeepAliveRequests. Statische minimale pagina\u2019s hebben zelden baat bij Keep-Alive; hier schakel ik het af en toe uit als tests duidelijke voordelen aantonen.<\/p>\n\n<h2>MPM en aanverwante richtlijnen op een zinvolle manier combineren<\/h2>\n\n<p>De Event-MPM gaat bijzonder zuinig om met inactieve verbindingen, waardoor een gematigde KeepAliveTimeout minder <strong>riskant<\/strong> 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 <strong>Risico's op aanvallen<\/strong> 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.<\/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>Stap-voor-stap-optimalisatie met monitoring<\/h2>\n\n<p>Ik begin met een verkeersanalyse: het aantal assets, de gebruikelijke laadtijden, het burst-gedrag en de pauzes tussen verzoeken zijn voor de <strong>Time-out<\/strong> cruciaal. Vervolgens stel ik een startwaarde in: 3 seconden voor gemengde workloads, 2 seconden voor API\u2019s, 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 <strong>wachttijd<\/strong>. Als er daarentegen steeds meer nieuwe verbindingen ontstaan en de latentie toeneemt, verhoog ik de tijd in kleine stapjes met 1\u20132 seconden. Een gestructureerde aanpak wordt beschreven in de korte <a href=\"https:\/\/webhosting.de\/nl\/keep-alive-webserver-prestatieoptimalisatiegids\/\">Handleiding voor het optimaliseren van de prestaties<\/a>.<\/p>\n\n<h2>Metrics lezen en correct interpreteren<\/h2>\n\n<p>Een blik op de serverstatus, de toegangslogboeken en de watervaldagrammen laat zien hoe verzoeken in de tijd samenvallen en hoe lang verbindingen <strong>stand<\/strong>. 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\u2019s 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 <strong>Werknemer<\/strong>. Zo kom ik stap voor stap dichter bij de sweet spot.<\/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>Workloadprofielen: website, API, proxy<\/h2>\n\n<p>Op websites met veel bestanden bundel ik meerdere verzoeken kort na elkaar op \u00e9\u00e9n <strong>Aansluiting<\/strong>, daarom is 3\u20135 seconden een goede tijd. API\u2019s hebben baat bij een tijd van amper 2\u20133 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\u20132 seconden, omdat de proxy de <strong>Klant<\/strong>-Persistentie neemt het over. Statische pagina\u2019s 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.<\/p>\n\n<h2>Tabel: Aanbevelingen en gevolgen van time-outs<\/h2>\n\n<p>In het volgende overzicht worden typische toepassingsscenario\u2019s aan concrete waarden gekoppeld en worden de belangrijkste effecten en risico\u2019s genoemd. Ik gebruik het als <strong>Startpunt<\/strong> 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 <strong>begrijpelijk<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Scenario<\/th>\n      <th>KeepAliveTimeout<\/th>\n      <th>MaxKeepAliveRequests<\/th>\n      <th>belangrijkste effect<\/th>\n      <th>mogelijk risico<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>API\/microservice<\/td>\n      <td>2\u20133 s<\/td>\n      <td>100-300<\/td>\n      <td>Snelle vrijgave, hogere doorvoer<\/td>\n      <td>Meer nieuwe verbindingen bij een te lage waarde<\/td>\n    <\/tr>\n    <tr>\n      <td>Website met veel materiaal<\/td>\n      <td>3\u20135 s<\/td>\n      <td>300\u2013500<\/td>\n      <td>Minder handshakes, kortere laadtijden<\/td>\n      <td>Bij overbelasting eventueel idle worker<\/td>\n    <\/tr>\n    <tr>\n      <td>Asset-domein (zeer veel bestanden)<\/td>\n      <td>5-10 s<\/td>\n      <td>500\u20131000<\/td>\n      <td>Goede bundeling van veel verzoeken<\/td>\n      <td>Langdurigere binding van verbindingen<\/td>\n    <\/tr>\n    <tr>\n      <td>Reverse-proxy v\u00f3\u00f3r Apache<\/td>\n      <td>1\u20132 s<\/td>\n      <td>100-300<\/td>\n      <td>Snelle backend, proxy onderhoudt clientverbindingen<\/td>\n      <td>Te kort bij zeldzame burst-reeksen<\/td>\n    <\/tr>\n    <tr>\n      <td>Statische minimale pagina<\/td>\n      <td>Uit of 1\u20132 s<\/td>\n      <td>laag<\/td>\n      <td>Maximale doorvoer per worker<\/td>\n      <td>Geen voordeel van hergebruik<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Ik gebruik deze waarden als een eerste routekaart en toets ze aan de hand van statistieken zoals openstaande <strong>Verbindingen<\/strong>, 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 <strong>harmonieus<\/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>Configuratie testen: hulpmiddelen en werkwijze<\/h2>\n\n<p>Ik valideer elke wijziging met synthetische belastingstests en echt verkeer, zodat de <strong>Gemeten waarden<\/strong> 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 <a href=\"https:\/\/webhosting.de\/nl\/http-keep-alive-tuning-serverbelasting-prestatieoptimalisatie-flow\/\">Optimalisatieproces<\/a>. Deze discipline zorgt ervoor dat ik effecten niet met toeval verwar <strong>moet<\/strong>.<\/p>\n\n<h2>HTTP\/2 en HTTP\/3: wat er verandert voor Keep-Alive<\/h2>\n<p>Met HTTP\/2 bundelt een client veel gelijktijdige streams via \u00e9\u00e9n 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\u00ebnter in \u00e9\u00e9n sessie verwerkt. In de praktijk zijn mijn webrichtwaarden (3\u20135 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.<\/p>\n\n<h2>HTTP Keep-Alive versus TCP-Keepalive: een duidelijk onderscheid maken<\/h2>\n<p>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.<\/p>\n\n<h2>Capaciteitsplanning: het worker-budget en de time-out in samenhang beschouwen<\/h2>\n<p>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 \u2018busy workers\u2019 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.<\/p>\n\n<h2>Time-outs in de stack consistent in evenwicht brengen<\/h2>\n<p>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 \u2013 en duidelijke veiligheidsbarri\u00e8res tegen misbruik.<\/p>\n\n<h2>TLS-kosten realistisch inschatten<\/h2>\n<p>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.<\/p>\n\n<h2>Mobiele netwerken, \u201elange pauzes\u201c en bescherming tegen misbruik<\/h2>\n<p>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\u20135 s), terwijl pure API\u2019s 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.<\/p>\n\n<h2>Apache, PHP-FPM en upstreams in harmonie<\/h2>\n<p>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 \u201eparkeren\u201c, terwijl verzoeken in de backend wachten op vrije PHP-slots \u2013 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.<\/p>\n\n<h2>Analysehandleiding voor lastige gevallen<\/h2>\n<p>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 \u00e9\u00e9n 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.<\/p>\n\n<h2>Economisch perspectief: kosten-baten in het dagelijks leven<\/h2>\n<p>Elke seconde KeepAliveTimeout \u201ekost\u201c mogelijk proces- en geheugenbronnen, maar \u201ebespaart\u201c TCP-\/TLS-overhead en vermindert de latentie. Ik beschouw dit als een investeringsbeslissing: voor API\u2019s 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 \u2013 en zorgt ervoor dat verbeteringen reproduceerbaar zijn, in plaats van alleen in benchmarks te schitteren.<\/p>\n\n<h2>WordPress- en hostingomgevingen in \u00e9\u00e9n oogopslag<\/h2>\n\n<p>WordPress-stacks combineren caching, dynamische PHP-verzoeken en talrijke <strong>Activa<\/strong>, daarom is een timeout-bandbreedte van 3\u20135 seconden een goed uitgangspunt. Bij een hoge gelijktijdige belasting verlaag ik dit naar 2\u20133 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 <strong>Prestaties<\/strong>-Tuning en een zorgvuldige configuratie spelen een belangrijke rol.<\/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 samengevat<\/h2>\n\n<p>Ik laat KeepAlive meestal ingeschakeld en stel een korte <strong>Time-out<\/strong>, zodat verbindingen op een zinvolle manier worden hergebruikt. Voor API\u2019s hanteer ik 2\u20133 seconden, voor standaardwebsites 3\u20135 seconden en voor asset-domeinen 5\u201310 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 <strong>Prestaties<\/strong> en minder vertraging. Zo bereik ik een hoge effici\u00ebntie zonder dat dit ten koste gaat van de stabiliteit en het verbruik van systeembronnen.<\/p>","protected":false},"excerpt":{"rendered":"<p>Leer hoe je de Apache KeepAlive-time-out optimaal instelt en de prestaties van je server verbetert door middel van gerichte configuratie. In deze handleiding wordt het focuszoekwoord \u2018apache keepalive timeout\u2019 uitgebreid uitgelegd.<\/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":"117","_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\/nl\/wp-json\/wp\/v2\/posts\/21159","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=21159"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21159\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21152"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21159"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21159"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21159"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}