Apache MPM event 2026 — den Thread-Pool dimensionieren, den wir tatsächlich betreiben

Jedes Mal, wenn wir einen neuen Kunden mit Apache httpd onboarden, schauen wir zuerst auf die MPM-Konfiguration. Etwa 70 % der Zeit ist es immer noch prefork, meist weil die Installation vor Jahren gebootstrappt wurde, als jemand mod_php brauchte, und sich nie wieder darum gekümmert hat. Weitere 20 % sind worker mit den Standardwerten aus dem Distro-Paket. Vielleicht 10 % sind event — und davon ist vielleicht die Hälfte angemessen dimensioniert.

Die drei MPMs, kurz

• prefork — ein Prozess pro Request, keine Threads. Riesiger Speicherbedarf. Hat überlebt, weil mod_php nicht thread-safe ist.
• worker — mehrere Prozesse, jeder mit mehreren Threads. Ein Thread ist über die gesamte Verbindungslebensdauer belegt, einschließlich leerlaufendem Keep-Alive.
• event — dieselben Threads wie worker, aber leerlaufende Keep-Alive-Verbindungen werden an einen dedizierten Listener mit epoll/kqueue zurückgegeben. Ein Thread ist nur belegt, während er tatsächlich Arbeit erledigt.

Für Keep-Alive-Workloads — und HTTP/2 heißt 2026, dass alles Keep-Alive ist — ist event materiell besser als worker. Auf einer belebten Site mit 5.000 gleichzeitigen Verbindungen ist das der Unterschied zwischen 5.000 Threads brauchen und vielleicht 400.

Die Zahlen, die wirklich zählen

Was wir auf einer typischen 4-vCPU / 8-GB-Apache-Box deployen, die PHP-FPM bedient:

<IfModule mpm_event_module>
    ServerLimit              16
    ThreadsPerChild          64
    MaxRequestWorkers        1024
    MaxConnectionsPerChild   10000
    AsyncRequestWorkerFactor 2
</IfModule>

MaxRequestWorkers ist der berühmte Knopf — aber bei event steuert es aktive Worker, nicht die Gesamtzahl der Verbindungen. AsyncRequestWorkerFactor ist der Multiplikator, der den Listener viel mehr leerlaufende Keep-Alives halten lässt, als MaxRequestWorkers vermuten lassen würde.

Der vollständige Medium-Beitrag behandelt:

• Warum prefork weg muss (und die PHP-FPM-Migration, die mod_php ersetzt)
• Wie man ServerLimit × ThreadsPerChild gegen die reale Concurrency dimensioniert
• Die MaxConnectionsPerChild-Begründung — und warum der Default von 0 falsch ist
• mod_status + apachetop lesen, um Ihr Tuning unter realer Last zu verifizieren
• Wo event noch gegen nginx verliert, und wo nicht

Weiter auf Medium.