Como seleciono qual MPM do Apache usar?

Esta é uma pergunta canônica sobre como selecionar o Apache httpd MPM correto.

Estou um pouco confuso entre os diferentes MPMs oferecidos pelo Apache - 'worker', 'event', 'prefork' etc.

Quais são as principais diferenças entre eles e como posso decidir qual será o melhor para uma determinada implantação?

Há uma série de módulos MPM (Multi-Processing Modules), mas, de longe, o mais utilizado (pelo menos em plataformas * nix) são os três principais: prefork, worker, e event. Essencialmente, eles representam a evolução do servidor da web Apache e as diferentes maneiras em que o servidor foi criado para lidar com solicitações HTTP dentro das restrições de computação do tempo ao longo de sua longa história (em termos de software).

prefork

mpm_preforké .. bem .. é compatível com tudo. Ele gera vários processos filhos para atender solicitações, e os processos filhos atendem apenas uma solicitação por vez. Como o processo do servidor está lá, pronto para a ação e sem a necessidade de lidar com o agrupamento de encadeamentos, é realmente mais rápido que os MPMs encadeados mais modernos quando você está lidando apenas com uma única solicitação por vez - mas as solicitações simultâneas sofrem, pois eles são feitos para esperar na fila até que um processo do servidor seja gratuito. Além disso, ao tentar aumentar a contagem de processos-filhos pré-fork, você sugará facilmente uma RAM séria.

Provavelmente não é aconselhável usar o prefork, a menos que você precise de um módulo que não seja seguro para threads.

Use if: Você precisa de módulos que quebrem quando threads são usados, como mod_php. Mesmo assim, considere usar o FastCGI e php-fpm.

Não use se: Seus módulos não quebram na segmentação.

worker

mpm_workerusa threading - o que é uma grande ajuda para a simultaneidade. O Worker gera alguns processos filhos, que, por sua vez, geram threads filhos; semelhante ao prefork, alguns threads sobressalentes são mantidos prontos, se possível, para atender às conexões de entrada. Essa abordagem é muito mais gentil na RAM, pois a contagem de threads não afeta diretamente o uso de memória, como a contagem de servidores no pré-fork. Ele também lida com a concorrência com muito mais facilidade, já que as conexões precisam apenas esperar por um encadeamento livre (que geralmente está disponível) em vez de um servidor sobressalente no prefork.

Use se: Você está no Apache 2.2 ou 2.4 e está executando principalmente SSL.

Não use se: Você realmente não pode dar errado, a menos que precise de pré-fork para compatibilidade.

No entanto, observe que os passos são anexados a conexões e não a solicitações - o que significa que uma conexão keep-alive mantém sempre um thread em espera até que ele seja fechado (o que pode levar muito tempo, dependendo da sua configuração). É por isso que temos ..

event

mpm_eventé muito semelhante ao trabalhador, estruturalmente; acabou de passar do status 'experimental' para 'estável' no Apache 2.4. A grande diferença é que ele usa um encadeamento dedicado para lidar com as conexões mantidas ativas, e envia solicitações para encadeamentos filhos apenas quando uma solicitação foi realmente feita (permitindo que esses encadeamentos façam backup imediatamente após a conclusão da solicitação). Isso é ótimo para a simultaneidade de clientes que não estão necessariamente ativos de cada vez, mas fazem solicitações ocasionais e quando os clientes podem ter um tempo limite longo e ativo.

A exceção aqui é com conexões SSL; nesse caso, ele se comporta de forma idêntica ao trabalhador (colando uma determinada conexão a um determinado encadeamento até que a conexão seja fechada).

Use if: Você está no Apache 2.4 e gosta de threads, mas não gosta de ter threads aguardando conexões inativas. Todo mundo gosta de tópicos!

Não use se: Você não está no Apache 2.4 ou precisa de pré-fork para compatibilidade.

No mundo atual de slowloris , AJAX e navegadores que gostam de multiplexar 6 conexões TCP (com keep-alive, é claro) para o servidor, a simultaneidade é um fator importante para tornar o servidor dimensionável e bem dimensionado. A história do Apache o vinculou a esse respeito e, embora ainda não esteja ao mesmo nível de nginx ou lighttpd em termos de uso ou escala de recursos, é claro que a equipe de desenvolvimento está trabalhando na construção de um servidor da web que ainda é relevante no mundo atual de alta solicitação e simultaneidade.

Aqui está uma boa explicação de como ele funciona com gifs:

https://www.datadoghq.com/blog/monitoring-apache-web-server-performance/

Resumidamente: se você está no 2.4 e precisa do httpd como proxy reverso (expedidor), sua escolha é um MPM de Evento

A partir de fevereiro de 2018, a documentação do Apache 2.4 para o MPM de eventos indica que o uso do Apache como proxy manterá o "tratamento aprimorado da conexão" desde a 2.4.24, conforme funcionado. Veja a seção Limitações .

O problema é que, como proxy, o trabalhador não pode dizer onde está o final da resposta e será forçado a esperar até que toda a resposta seja vista antes de retornar o controle ao ouvinte.

Por esse motivo, parece que usar o modelo Worker pode ser melhor para quando o apache é usado como proxy. Não está realmente claro para mim se existem vantagens para o modelo de evento em um ambiente proxy, mas talvez haja.

Depende principalmente de quais módulos do Apache você deseja usar. Eu acho que worker geralmente é a opção padrão, mas alguns módulos (mais antigos) exigem bifurcação e dependem do prefork.

Se você não tiver preferências, recomendo que você escolha a dependência preferida da sua distribuição do SO. O Ubuntu, por exemplo, instalará o mpm-worker por padrão quando você instalar o Apache2.