{"id":21581,"date":"2026-09-20T08:31:58","date_gmt":"2026-09-20T06:31:58","guid":{"rendered":"https:\/\/webhosting.de\/apache-event-queue-verstehen-event-mpm-apache-hosting-optimierung\/"},"modified":"2026-09-20T08:31:58","modified_gmt":"2026-09-20T06:31:58","slug":"apache-gebeurteniswachtrij-begrijpen-event-mpm-apache-hostingoptimalisatie","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/apache-event-queue-verstehen-event-mpm-apache-hosting-optimierung\/","title":{"rendered":"Inzicht in de Apache Event Queue: basisprincipes, werking en optimalisatie met Event MPM"},"content":{"rendered":"<p>Ik leg kort en duidelijk uit hoe <strong>Evenement MPM<\/strong> die gebruikmaakt van de Apache Event Queue om een groot aantal gelijktijdige HTTP-verbindingen effici\u00ebnt te beheren. Daarbij leg ik de basisprincipes uit, zoals de event-loop, interne wachtrijen en concrete optimalisatiestappen voor een <strong>performant<\/strong> Configuratie.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>Gebeurtenis lus<\/strong> maakt een onderscheid tussen verbindingsbeheer en het verwerken van verzoeken<\/li>\n  <li><strong>Keep-Alive<\/strong> blokkeert geen threads meer<\/li>\n  <li><strong>Evenementenwachtrij<\/strong> sorteert sockets op status<\/li>\n  <li><strong>Parameters<\/strong> hoe je MaxRequestWorkers gericht kunt afstemmen<\/li>\n  <li><strong>Controle<\/strong> zorgt voor een betrouwbare capaciteitsplanning<\/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\/09\/apache-event-queue-4893.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hoe Event MPM verbindingen regelt<\/h2>\n\n<p>Ik begin met de vraag hoe Apache onder <strong>Belasting<\/strong> zoveel verbindingen beheert. Event MPM combineert processen en threads, maar geeft voorrang aan gebeurtenissen via een event-loop. Listener-threads accepteren nieuwe sockets en houden bestaande verbindingen in de gaten, zonder meteen een worker te blokkeren. Pas zodra gegevens leesbaar of schrijfbaar zijn, draagt de gebeurtenislaag de socket over aan een vrije werkthread. Zo voorkom ik dat <strong>stationair draaien<\/strong>-Verbindingen nemen threads in beslag en verspillen geheugen.<\/p>\n\n<p>Deze scheiding vermindert de belasting van het RAM-geheugen merkbaar. Threads voeren vooral \u201eecht werk\u201c uit, zoals het parseren van verzoeken, het genereren van antwoorden of het fungeren als proxy. De event-loop brengt de sockets daarna weer in de juiste toestand, bijvoorbeeld terug naar Keep-Alive of naar de afsluitfase. In de praktijk zie ik kortere wachtrijen bij piekbelasting, omdat vrije threads sneller weer beschikbaar komen. De architectuur biedt een duidelijke <strong>schaalbare<\/strong> Reactievermogen voor typische HTTP\/1.1- en HTTP\/2-workloads.<\/p>\n\n<h2>De Apache Event Queue in detail<\/h2>\n\n<p>De Event Queue wijst aan elke verbinding een status toe, en juist hier ligt de <strong>Winst<\/strong> in vergelijking met klassieke MPM\u2019s. Nieuwe verbindingen komen eerst in een wachtrij terecht die controleert of ze leesbaar zijn. Zodra er gegevens binnenkomen, verplaatst de event-loop de socket naar een \u201ereadable\u201c-wachtrij en wijst deze toe aan een worker. Na de verwerking bepaalt de status opnieuw: het schrijven be\u00ebindigen, Keep-Alive in de wacht zetten of sluiten. Deze cyclus blijft slank, omdat het wachtrijbeheer op een kosteneffici\u00ebnte manier via epoll of kqueue wordt afgehandeld.<\/p>\n\n<p>Ik zie vaak misverstanden: de Event Queue vervangt geen workers, maar co\u00f6rdineert hun <strong>Gebruik<\/strong> effici\u00ebnter. Threads blijven verzoeken verwerken, maar alleen als er daadwerkelijk bytes worden verzonden. Dit ontlast de CPU en het geheugen in scenario\u2019s met veel \u201einactieve\u201c keep-alive-verbindingen. Hoe strakker het ontwerp van time-outs en buffers, hoe kleiner het risico dat verbindingen onnodig lang in kostbare statussen blijven hangen. Zo kan de responstijd constant worden gehouden, zelfs bij duizenden open sockets.<\/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\/09\/apache_event_queue_meeting2023_4123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Het keep-alive-probleem bij klassieke MPM\u2019s<\/h2>\n\n<p>Bij HTTP\/1.1 blijven verbindingen vaak open om meerdere verzoeken te verzenden zonder een nieuwe handshake, wat <strong>Latency<\/strong> bespaart. Prefork of Worker reserveren hiervoor echter processen of threads die alleen maar wachten. Bij piekbelastingen blokkeren veel keep-alive-verbindingen dan waardevolle uitvoeringsbronnen. Dit drijft het RAM-verbruik omhoog en beperkt het aantal parallelle clients. Event MPM lost dit op door in de Event Queue inactieve sockets zonder thread in een gunstige wachtstand te houden.<\/p>\n\n<p>Zo zet ik een groot aantal verbindingen in de wacht en begin ik pas met de verwerking wanneer dat daadwerkelijk nodig is. Dit verandert het capaciteitsmodel: in plaats van \u2018threads = verbindingen\u2019 hanteer ik \u2018threads = actief werk\u2019. In benchmarkscenario\u2019s kan ik daardoor aanzienlijk meer open verbindingen toestaan, zonder dat dit ten koste gaat van de <strong>Reactietijd<\/strong>. Voor API-backends, WordPress-hosting en grote inhoudssites betekent dit een aanzienlijk gelijkmatiger belasting. De voordelen van Keep-Alive blijven behouden, zonder dat threads worden geblokkeerd.<\/p>\n\n<h2>Event MPM versus Worker MPM<\/h2>\n\n<p>Ik vat de verschillen kort samen in een <strong>Tabel<\/strong> samen. Het doel is om in \u00e9\u00e9n oogopslag een beeld te krijgen van de bediening, de benodigde systeembronnen en typische toepassingsgebieden. Beide varianten maken gebruik van processen met meerdere threads, maar bij Event wordt Keep-Alive minder vaak aan \u00e9\u00e9n thread gekoppeld. Worker blijft betrouwbaar bij een gematigde belasting, terwijl Event uitblinkt bij veel gelijktijdige verbindingen. Deze indeling helpt bij het nemen van weloverwogen beslissingen voor de eigen omgeving. Een meer diepgaande vergelijking vind je onder <a href=\"https:\/\/webhosting.de\/nl\/apache-event-mpm-versus-worker-mpm-afstemming-en-optimalisatie-van-de-webserver\/\">Evenement versus werknemer<\/a>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>MPM<\/th>\n      <th>Keep-Alive-verwerking<\/th>\n      <th>Threads\/processen<\/th>\n      <th>RAM-vereiste<\/th>\n      <th>Geschikt voor<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Voorkurk<\/td>\n      <td><strong>Proces<\/strong> blokkeert bij stationair draaien<\/td>\n      <td>Alleen processen<\/td>\n      <td>Hoog<\/td>\n      <td>Oude PHP zonder threadveiligheid<\/td>\n    <\/tr>\n    <tr>\n      <td>Werknemer<\/td>\n      <td><strong>Discussie<\/strong> blijft vaak vastzitten<\/td>\n      <td>Processen + threads<\/td>\n      <td>Medium<\/td>\n      <td>Matige belasting, eenvoudige installaties<\/td>\n    <\/tr>\n    <tr>\n      <td>Evenement<\/td>\n      <td><strong>Gebeurtenis lus<\/strong> slaat inactieve sockets op<\/td>\n      <td>Processen + threads<\/td>\n      <td>Laag tot gemiddeld<\/td>\n      <td>Veel clients, lange keep-alive-fasen<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/apache-event-queue-optimization-5281.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Typische toepassingsscenario's<\/h2>\n\n<p>Ik gebruik Event MPM wanneer er veel parallelle <strong>Klanten<\/strong> kleine tot middelgrote payloads opvragen. Blogs met veel verkeer, webwinkels met caching, statische assets en API-eindpunten profiteren hier merkbaar van. Hetzelfde geldt voor hostingopstellingen met veel websites per server, waarin keep-alive-verbindingen de overhand hebben. De Event Queue houdt daar het aantal actieve threads laag en verdeelt het werk gelijkmatig. Wie HTTP\/2 gebruikt, profiteert nog eens extra, omdat \u00e9\u00e9n verbinding meerdere streams kan verwerken, terwijl de Event-laag de statussen netjes co\u00f6rdineert.<\/p>\n\n<p>Ook bij reverse-proxy-topologie\u00ebn laat Event zijn sterke punten zien. Ik laat Apache de SSL-verbinding tot stand brengen, het caching verzorgen en verzoeken doorgeven aan een applicatielaag. Daarbij blijft het verbindingsbeheer lichtgewicht, wat knelpunten voorkomt. Zelfs bij pieken in het verkeer blijven de responstijden beheersbaar, mits de limieten verstandig zijn ingesteld. Dat verlaagt het risico op <strong>Wachtrij<\/strong>-Opstopping en time-outs.<\/p>\n\n<h2>Configuratie: sleutelrichtlijnen<\/h2>\n\n<p>Om tot een weloverwogen besluit te komen, kijk ik eerst naar <strong>ServerLimit<\/strong>, StartServers, ThreadsPerChild en MaxRequestWorkers. De vuistregel: ServerLimit \u00d7 ThreadsPerChild moet dicht bij MaxRequestWorkers liggen, met een marge voor onderhoud en groei. Een te lage waarde remt de parallelliteit af, een te hoge waarde zorgt voor een te hoog RAM-verbruik. Ik zet KeepAlive op On, maar stel KeepAliveTimeout gematigd in, zodat inactiviteit niet uit de hand loopt. Waarden tussen enkele seconden en lage dubbele cijfers werken vaak goed, afhankelijk van het verkeersprofiel.<\/p>\n\n<p>Verder houd ik rekening met time-outs voor lezen, schrijven en proxyservers. Kortere waarden voorkomen dat backends vastlopen, langere waarden helpen bij traag reagerende clients, wat <strong>Afwegingen<\/strong> is vereist. Voor statische bestanden loont het om in grotere blokken te verzenden en effici\u00ebnte filterketens te gebruiken. Bij PHP via FPM of proxy-loadbalancers schaal ik het aantal backend-workers af op de parallelliteit van de frontend. Ik documenteer elke wijziging en meet het effect voordat ik verder ga.<\/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\/09\/apache_event_queue_tech_9254.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>De event-wachtrij afstemmen: stap voor stap<\/h2>\n\n<p>Ik begin met een duidelijke <strong>lastprofiel<\/strong>: gelijktijdige verbindingen, verzoeken per seconde, antwoordgroottes, Keep-Alive-percentages. Vervolgens stel ik MaxRequestWorkers zo in dat de CPU niet inactief blijft, maar het RAM-geheugen ruimschoots toereikend is. Ik pas ThreadsPerChild aan totdat pieken in de belasting zonder wachttijd worden verwerkt. Ik stel KeepAliveTimeout zo in dat er een goede balans ontstaat tussen gebruikerservaring en het spaarzaam omgaan met systeembronnen. Wie het gedrag van wachtrijen beter wil begrijpen, vindt basisinformatie op <a href=\"https:\/\/webhosting.de\/nl\/webserver-wachtrij-latentie-verzoekafhandeling-serverwachtrij\/\">Webserver in de wachtrij<\/a>.<\/p>\n\n<p>Ik voer iteratieve tests uit met tools zoals ab, wrk of k6 en analyseer de latentie in de P50, P95 en P99. Daarbij houd ik in de gaten wanneer verbindingen in keep-alive blijven en wanneer ze worden verbroken. Een lichte overprovisionering van threads helpt om korte pieken op te vangen zonder de machine te overbelasten. Tegelijkertijd controleer ik foutlogboeken op meldingen zoals \u201eserver reached MaxRequestWorkers\u201c. Zo krijg ik een <strong>harmonieus<\/strong> Samenwerking tussen de event-wachtrij en de worker-pool.<\/p>\n\n<h2>Bewaking en statistieken<\/h2>\n\n<p>Goede statistieken zorgen voor een betrouwbare <strong>Capaciteit<\/strong>. Ik activeer mod_status en houd actieve, inactieve en wachtende workers bij. Het scorebord laat zien of er verzoeken in de wachtrij staan of dat er resources vrij zijn. Daarnaast meet ik het aantal processen en threads, het RAM-gebruik en de netwerk-I\/O. Een visuele analyse helpt bij het herkennen van trends en omslagpunten. Meer details vindt u in het <a href=\"https:\/\/webhosting.de\/nl\/apache-scoreboard-gedetailleerde-monitoring-van-de-serverbelasting\/\">Apache Scoreboard<\/a>.<\/p>\n\n<p>Ik breng deze waarden in verband met Access-logs en foutcodes. Als het aantal 5xx-fouten toeneemt terwijl de belasting maximaal is, zijn de limieten vaak te laag. Als time-outs toenemen, controleer ik de backend-services, de DNS-resolutie en de netwerkpaden. Ik kijk bij hoge belasting ook naar TCP-backlogs en SYN-hertransmissies. Zo kan ik vaststellen of de <strong>Oorzaak<\/strong> in de webserver, in de backend of in het netwerk ligt.<\/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\/09\/apache-event-queue-4938.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>HTTP\/2, reverse proxy en modules<\/h2>\n\n<p>HTTP\/2 bundelt meerdere streams via \u00e9\u00e9n verbinding, wat de <strong>Evenement<\/strong>-architectuur optimaal ondersteunt. Ik let op de balans tussen streamlimieten en de threadpool, zodat veel kleine streams niet in wachtrijen terechtkomen. Als reverse proxy profiteert Apache van korte time-outs en betrouwbare backend-verbindingen. Modules die sterk blokkerend werken, kunnen echter threads vastleggen en de voordelen verminderen. Ik controleer daarom de compatibiliteit en vervang verouderde componenten als deze pieken in de latentie veroorzaken.<\/p>\n\n<p>Cachemodules en compressie verhogen de effici\u00ebntie, mits de CPU-profielen hierop zijn afgestemd. TLS-optimalisatie met moderne versleutelingsalgoritmen en HTTP\/2-prioritering dragen bij aan een snelle levering. Ik maak gebruik van sessieherstel en houd de handshake-kosten onder belasting in de gaten. Voor statische assets werken zero-copy-benaderingen en sendfile goed. De <strong>Kunst<\/strong> ligt in het slank houden van de keten bestaande uit TLS, de event queue, de worker en de backend.<\/p>\n\n<h2>Interne workflow en statussen in de MPM-event<\/h2>\n\n<p>Om de interne processen te begrijpen, denk ik in <strong>toestanden<\/strong>: accept \u2192 readable \u2192 processing \u2192 writable \u2192 keep-alive \u2192 close. Listener-threads houden toezicht op sockets met behulp van effici\u00ebnte kernelmechanismen (epoll\/kqueue) en wekken workers alleen als er een gebeurtenis plaatsvindt. Na het verwerken van een verzoek beslist de gebeurtenislaag of de verbinding in de \u201ekeep-alive\u201c-status wordt gehouden, direct wordt gesloten of wordt afgesloten op een manier die lijkt op een \u201elingering close\u201c, zodat laat binnenkomende TCP-pakketten correct worden verwerkt. Deze toestandsautomaat voorkomt \u2018busy waiting\u2019 en minimaliseert contextwisselingen.<\/p>\n\n<p>Belangrijk daarbij is het onderscheid tussen <strong>I\/O-wachttijd<\/strong> en CPU-belasting: het parseren van verzoeken, filterpijplijnen (bijv. compressie) en het genereren van het antwoord vinden plaats in werkthreads. Het louter wachten op leesbaarheid\/schrijfbaarheid blijft in de event-loop. Hierdoor maakt Apache beter gebruik van de beschikbare threads en vermindert de <strong>Draaddichtheid<\/strong> per open verbinding drastisch.<\/p>\n\n<p>Ik houd bovendien rekening met het gedrag van het scoreboard: in mod_status zijn fasen zoals \u201eR\u201c (Reading), \u201eW\u201c (Sending Reply), \u201eK\u201c (Keepalive) en \u201eG\u201c (Gracefully finishing) af te lezen. Een hoog \u201eK\u201c-percentage bij tegelijkertijd beschikbare workers geeft aan dat de event-wachtrij correct wordt geparkeerd en geen threads verspilt. Als de \u201eR\u201c-tijden aanzienlijk stijgen, duidt dit op trage clients of te restrictieve read-time-outs, wat wijst op optimalisatiemogelijkheden.<\/p>\n\n<h2>Planning van hulpbronnen: rekenvoorbeeld en zinvolle standaardinstellingen<\/h2>\n\n<p>Ik bereken de <strong>Parallellisme<\/strong> bestaande uit CPU, RAM en workload. Een voorbeeld: 8 vCPU, 16 GB RAM, voornamelijk gecachete inhoud en PHP-FPM in de backend. Ik begin met MaxRequestWorkers 512\u2013768, ThreadsPerChild 32\u201364 en ServerLimit dienovereenkomstig 8\u201312. Ik houd per actieve worker rekening met 1\u20133 MB Apache-overhead plus modules, plus responsbuffers, TLS-overhead en backend-sockets. Realistisch gezien reserveer ik 4\u20138 GB voor Apache-processen\/threads, 2\u20134 GB voor de OS-cache en de rest voor backends. Ik let erop dat <strong>ServerLimit \u00d7 ThreadsPerChild<\/strong> nooit kleiner is dan MaxRequestWorkers; een beetje speling is verstandig.<\/p>\n\n<p>Een overzicht van nuttige richtlijnen:\n\u2013 <strong>MinSpareThreads\/MaxSpareThreads<\/strong>: Zorg ervoor dat de reserve zo is ingesteld dat piekbelastingen worden opgevangen zonder dat er een \u201ekoude start\u201c nodig is, maar dat er niet te veel inactieve threads geheugen in beslag nemen.\n\u2013 <strong>MaxConnectionsPerChild<\/strong> (ook bekend als MaxRequestsPerChild): Een eindige levenscyclus per proces helpt om geheugenfragmentatie en -lekken bij langdurig gebruik te voorkomen (bijv. 5k\u201320k).\n\u2013 <strong>MaxKeepAliveRequests<\/strong>: Beperkt het aantal verzoeken per verbinding; gematigde waarden voorkomen \u201eeindeloze\u201c sessies zonder afbreuk te doen aan het voordeel van Keep-Alive (bijv. 100\u20131000).\n\u2013 <strong>Time-out<\/strong>, <strong>Time-outs bij lezen\/schrijven<\/strong> en <strong>ProxyTimeout<\/strong>: Voorkom vastlopers; ik stel per context verschillende waarden in, in plaats van globaal te conservatief te zijn.<\/p>\n\n<p>Voor statische bestanden gebruik ik <strong>EnableSendfile<\/strong> en <strong>EnableMMAP<\/strong> bewust: op lokale schijven kunnen beide voordelen opleveren; bij NFS\/cloudvolumes schakel ik sendfile vaak uit om uitzonderingsgevallen te voorkomen. In TLS-paden heeft sendfile vanwege de opbouw ervan minder effect, aangezien gegevens door versleutelingspijplijnen lopen; hier telt vooral een effici\u00ebnte <strong>Filterketen<\/strong>.<\/p>\n\n<h2>Beperkingen van het besturingssysteem en het netwerk<\/h2>\n\n<p>Zelfs de beste evenementarchitectuur heeft weinig nut als beperkingen van het besturingssysteem een rem zetten op de prestaties. Ik controleer:\n\u2013 <strong>Bestandsdescriptoren<\/strong> (ulimit -n): De waarde moet ruim boven het maximale aantal gelijktijdige verbindingen plus backend-sockets liggen; enkele tienduizenden zijn gebruikelijk voor drukbezochte hosts.\n\u2013 <strong>LuisterBacklog<\/strong>: Een voldoende grote accept-backlog voorkomt dat SYN-pakketten tijdens pieken worden afgewezen.\n\u2013 <strong>Kernel-achterstanden<\/strong> (bijv. somaxconn) en SYN-wachtrijen: deze moeten overeenkomen met de verwachte \u201eburst\u201c-snelheid.\n\u2013 <strong>Netwerkbuffer<\/strong> (rmem\/wmem): Niet overdrijven, maar zo dimensioneren dat verbindingen met een hoge RTT of hoge bandbreedte niet instorten.<\/p>\n\n<p>Ik verdeel de accept-belasting over meerdere listener-threads en laat het platform in de regel het accept-mechanisme kiezen (AcceptMutex auto). Op systemen die dit ondersteunen, kan <strong>SO_REUSEPORT<\/strong> (afhankelijk van het platform via de lijstoptie) de acceptatiepaden afvlakken. Het is belangrijk om \u2018thundering herd\u2019-situaties te vermijden, waarbij veel threads om dezelfde acceptatie strijden.<\/p>\n\n<p>Ook <strong>Tijdelijke TCP-poorten<\/strong> (ip_local_port_range) en het TIME-WAIT-gedrag moeten aansluiten bij het aantal parallelle proxyverbindingen. Ik vermijd agressieve aanpassingen, maar test op realistische wijze en zorg ervoor dat backends Keep-Alive ondersteunen, zodat verbindingen opnieuw kunnen worden gebruikt en er minder poortwisselingen plaatsvinden.<\/p>\n\n<h2>De fijne kneepjes van reverse-proxy\u2019s: verbindingspools en backends<\/h2>\n\n<p>Als reverse proxy hangt de algehele prestatie sterk af van stabiele backend-verbindingen. Ik zorg ervoor dat <strong>Proxyverbindingen<\/strong> Zorg voor persistentie (Keep-Alive naar de backend) en dimensionneer de backend-pools zo dat ze de parallelliteit van de frontend volgen. Te kleine pools veroorzaken frontend-opstoppingen, te grote pools zorgen voor onnodige belasting van de app.<\/p>\n\n<p>Praktische aanpassingsmogelijkheden:\n\u2013 <strong>ProxyTimeout<\/strong>: Korter voor niet-kritieke paden, langer voor \u201edure\u201c eindpunten \u2013 maak onderscheid, pas geen algemene regels toe.\n\u2013 <strong>Balancer<\/strong>-Instellingen (voor mod_proxy_balancer): wegingsfactoren, maximaal aantal verbindingen per backend, op de status afgestemde herhalingsintervallen.\n\u2013 <strong>mod_proxy_fcgi<\/strong> voor PHP-FPM: De FPM-<strong>pm.*<\/strong>-Waarden (pm.max_children, pm.start_servers enz.) moeten worden afgestemd op de parallelliteit van Apache om pieken in 502\/504-fouten te voorkomen.<\/p>\n\n<p>Ik zorg ervoor dat backend-fouten netjes en snel worden ge\u00ebscaleerd, in plaats van frontend-threads te blokkeren. Health-checks, een voorzichtig herpogingsbeleid en circuit-breaker-achtige patronen houden de latentie stabiel. Waar mogelijk zorg ik voor <strong>Caching van antwoorden<\/strong> op geschikte plaatsen, zodat het evenement MPM vooral korte, beknopte antwoorden kan versturen.<\/p>\n\n<h2>HTTP\/2-fijnafstemming onder Event<\/h2>\n\n<p>Voor HTTP\/2 optimaliseer ik, naast TLS, vooral <strong>Streamlimieten<\/strong> en toewijzing van workers. Veel kleine streams per verbinding kunnen de latentie verlagen, maar de threadbelasting verhogen. Ik stel het maximale aantal streams per sessie zo in dat multiplexing wordt toegepast, maar er geen \u201ehead-of-line\u201c-vervanging ontstaat. Daarnaast schaal ik het aantal workers voorzichtig op, zodat piekperiodes worden opgevangen zonder het RAM-geheugen te overbelasten.<\/p>\n\n<p>Het valt me op hoe vaak streams moeten wachten, ook al zijn er threads vrij. Als dat het geval is, wordt de doorvoersnelheid meestal beperkt door streamlimieten of buffergroottes. Een <strong>Prioritering<\/strong> Het gebruik van kritieke bronnen (bijv. CSS\/JS via HTTP\/2-prioriteiten) heeft een directe invloed op de waargenomen prestaties. Wat TLS betreft, verlagen sessiehervatting, 0-RTT-achtige mechanismen (voor zover deze veilig en beschikbaar zijn) en moderne versleutelingsalgoritmen de kosten van de handshake.<\/p>\n\n<h2>Robuustheid: time-outs, bescherming tegen Slowloris en een soepele uitschakeling<\/h2>\n\n<p>Ik activeer <strong>mod_reqtimeout<\/strong>, om \u2018slowloris\u2019-achtige patronen te neutraliseren. Time-outs voor het lezen voorkomen dat clients bytes in een slakkengang afleveren en zo bronnen bezetten. Time-outs voor het schrijven bieden bescherming tegen trage verbindingen naar de client. Deze waarden moeten contextgebonden worden gekozen \u2013 API\u2019s vereisen andere profielen dan het downloaden van grote bestanden.<\/p>\n\n<p>Voor roll-outs en herstarts vertrouw ik op <strong>Sierlijke<\/strong>-Processen. Met een zinvolle \u201egraceful timeout\u201c lopen oude processen op gecontroleerde wijze af, terwijl nieuwe processen het overnemen. Zo blijven keep-alive-verbindingen stabiel en verwerkt de eventqueue de resterende belasting zonder abrupte onderbrekingen. Roterende logbestanden, een lage log-verbaliteit tijdens piekuren (bijv. \u201einfo\u201c in plaats van \u201edebug\u201c) en optioneel <strong>BufferedLogs<\/strong> verlagen de I\/O-belasting merkbaar.<\/p>\n\n<h2>Foutopsporing onder belasting: patronen herkennen<\/h2>\n\n<p>Typische symptomen en benaderingen:\n\u2013 Hoge <strong>P95\/P99<\/strong>-Vertragingen bij vrije workers: meestal wachttijden aan de backend- of netwerkzijde; controleer proxy- en leestime-outs en backend-pools.\n\u2013 \u201eserver reached MaxRequestWorkers\u201c: te weinig parallelliteit \u2013 verhoog MaxRequestWorkers en\/of ThreadsPerChild, controleer het RAM-gebruik.\n\u2013 Veel <strong>Keep-Alive<\/strong>-Verbindingen, weinig actieve threads, maar toch traag: vaak blokkerende modules\/filters of backend-bottlenecks; profileer de filterketen, controleer CPU-bezetting en I\/O.\n\u2013 5xx-pieken die samenhangen met de TLS-belasting: CPU-gebonden handshakes \u2013 versleutelingsalgoritmen, sessieherstel en eventueel offload optimaliseren.<\/p>\n\n<p>Ik pak knelpunten in de keten aan: socket-acceptatie (backlog), event-loop (wachttoestanden), workers (CPU-gebonden), filters (I\/O-gebonden), proxy (backend-gebonden). Dit denkkader voorkomt dat ik aan MaxRequestWorkers ga sleutelen, terwijl de backend eigenlijk de bottleneck is.<\/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\/09\/apache-event-queue-9023.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Checklist voor de praktijk en veelvoorkomende valkuilen<\/h2>\n\n<p>Ik werk met een korte <strong>Checklist<\/strong>: actuele Apache-versie, Event MPM geactiveerd, limieten correct ingesteld, time-outs zinvol. Vervolgens controleer ik de Keep-Alive-frequenties en de verhouding tussen verbindingen en actieve threads. Ik controleer of modules thread-safe zijn en of filters geen langdurige blokkades veroorzaken. Voor PHP via FPM zorg ik ervoor dat het aantal FPM-workers is afgestemd op de parallelliteit van de frontend. Ook stel ik OS-limieten in, zoals file descriptors, TCP-backlog en kernelparameters voor netwerkbuffers, zodat de <strong>Pijpleiding<\/strong> niet vastloopt.<\/p>\n\n<p>Veelvoorkomende struikelblokken herken ik snel: te lange KeepAliveTimeouts, te weinig MaxRequestWorkers, een te lage ThreadsPerChild of ongeschikte logboekregistratie. Overdreven gedetailleerde logboekregistratie slokt I\/O op en vertraagt de reactietijden. Een te kleine proxy-backend-poolgrootte doet afbreuk aan frontend-optimalisatie. Verkeerde TLS-configuraties verlengen handshakes onnodig. Wie deze punten goed op orde heeft, cre\u00ebert een <strong>betrouwbare<\/strong> De basis voor constante latenties.<\/p>\n\n<h2>Samenvatting voor technisch verantwoordelijken<\/h2>\n\n<p>Event MPM maakt een duidelijk onderscheid tussen verbindingsbeheer en uitvoering en kiest voor een <strong>Evenementenwachtrij<\/strong>, die inactieve verbindingen op een effici\u00ebnte manier parkeert. Hierdoor schaalt Apache bij veel gelijktijdige clients, zonder dat er threads in de lucht blijven hangen. De juiste combinatie van MaxRequestWorkers, ThreadsPerChild en doordachte time-outs houdt de latentie en het RAM-gebruik binnen de perken. Door voortdurende monitoring, benchmarking en enkele gerichte aanpassingen ontstaat een systeem dat pieken opvangt en consistent reageert. Wie deze principes ter harte neemt, haalt het maximale uit zijn <strong>Apache<\/strong>-De installatie biedt aanzienlijk meer mogelijkheden en blijft tegelijkertijd compatibel met gangbare toepassingen en protocollen.<\/p>","protected":false},"excerpt":{"rendered":"<p>Inzicht in de Apache Event Queue: ontdek hoe de Event MPM de prestaties van je Apache-webserver verbetert en waarom de Event-architectuur met Event MPM ideaal is voor moderne hostingomgevingen.<\/p>","protected":false},"author":1,"featured_media":21574,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21581","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":"80","_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":"Event MPM","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":"21574","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21581","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=21581"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21581\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21574"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21581"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21581"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21581"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}