Apache MPM event en 2026 — dimensionar el thread pool que de verdad operamos

Cada vez que hacemos onboarding de un nuevo cliente con Apache httpd, lo primero que miramos es la configuración del MPM. Alrededor del 70 % del tiempo sigue siendo prefork, normalmente porque la instalación se bootstrapeó hace años cuando alguien necesitaba mod_php y nunca volvió. Otro 20 % es worker con los valores por defecto del paquete de distribución. Quizás un 10 % es event — y de esos, tal vez la mitad está bien dimensionado.

Los tres MPMs, en breve

• prefork — un proceso por petición, sin hilos. Huella de memoria enorme. Sobrevivió porque mod_php no es thread-safe.
• worker — múltiples procesos, cada uno con múltiples hilos. Un hilo está ocupado durante toda la vida de la conexión, incluyendo el keep-alive ocioso.
• event — los mismos hilos que worker, pero las conexiones keep-alive ociosas se entregan a un listener dedicado usando epoll/kqueue. Un hilo solo está ocupado mientras realmente hace trabajo.

Para cargas keep-alive — y HTTP/2 significa que todo es keep-alive en 2026 — event es materialmente mejor que worker. En un sitio ocupado con 5 000 conexiones concurrentes, esa es la diferencia entre necesitar 5 000 hilos y necesitar quizás 400.

Los números que de verdad importan

Lo que desplegamos en una caja Apache típica de 4-vCPU / 8 GB sirviendo PHP-FPM:

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

MaxRequestWorkers es el botón famoso — pero en event controla los workers activos, no el total de conexiones. AsyncRequestWorkerFactor es el multiplicador que permite al listener mantener muchos más keep-alives ociosos de lo que MaxRequestWorkers sugeriría.

El post completo en Medium recorre:

• Por qué prefork debe irse (y la migración a PHP-FPM que reemplaza mod_php)
• Cómo dimensionar ServerLimit × ThreadsPerChild contra tu concurrencia real
• El razonamiento de MaxConnectionsPerChild — y por qué el default de 0 está mal
• Leer mod_status + apachetop para verificar tu tuning bajo carga real
• Dónde event aún pierde frente a nginx, y dónde no

Continúa en Medium.