Apache MPM event em 2026 — dimensionar o thread pool que de fato rodamos

Toda vez que fazemos onboarding de um novo cliente com Apache httpd, a primeira coisa que olhamos é a configuração do MPM. Cerca de 70 % das vezes ainda é prefork, geralmente porque a instalação foi bootstrappada anos atrás quando alguém precisou de mod_php e nunca voltou. Mais 20 % é worker com os defaults do pacote da distro. Talvez 10 % seja event — e desses, talvez metade esteja dimensionada apropriadamente.

Os três MPMs, em resumo

• prefork — um processo por request, sem threads. Pegada de memória enorme. Sobreviveu porque mod_php não é thread-safe.
• worker — múltiplos processos, cada um com múltiplas threads. Uma thread fica ocupada pela vida inteira da conexão, incluindo keep-alive ocioso.
• event — mesmas threads do worker, mas conexões keep-alive ociosas são entregues de volta a um listener dedicado usando epoll/kqueue. Uma thread só fica ocupada enquanto faz trabalho de fato.

Para cargas keep-alive — e HTTP/2 significa que tudo é keep-alive em 2026 — event é materialmente melhor que worker. Em um site ocupado com 5 000 conexões concorrentes, é a diferença entre precisar de 5 000 threads e precisar de talvez 400.

Os números que realmente importam

O que implantamos em uma máquina Apache típica de 4-vCPU / 8 GB servindo PHP-FPM:

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

MaxRequestWorkers é o botão famoso — mas em event controla workers ativos, não o total de conexões. AsyncRequestWorkerFactor é o multiplicador que permite ao listener manter muito mais keep-alives ociosos do que MaxRequestWorkers sugeriria.

O post completo no Medium passa por:

• Por que prefork tem que ir (e a migração para PHP-FPM que substitui mod_php)
• Como dimensionar ServerLimit × ThreadsPerChild contra a sua concorrência real
• O raciocínio de MaxConnectionsPerChild — e por que o default de 0 está errado
• Ler mod_status + apachetop para verificar seu tuning sob carga real
• Onde event ainda perde para o nginx, e onde não perde

Continua no Medium.