Como seleciono qual Apache MPM usar?

Existem vários módulos MPM (Multi-Processing Modules), mas de longe os mais usados ​​(pelo menos em plataformas *nix) são os três principais: prefork, worker, e event. Essencialmente, eles representam a evolução do servidor web Apache e as diferentes maneiras que o servidor foi construído para lidar com solicitações HTTP dentro das restrições de computação da época ao longo de seu longo histórico (em termos de software).

prefork

mpm_preforké.. bem.. é compatível com tudo. Ele desmembra vários processos filho para atender solicitações, e os processos filho atendem apenas uma solicitação por vez. Como ele tem o processo do servidor parado, pronto para a ação e não precisa lidar com o empacotamento de threads, é realmente mais rápido do 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, uma vez que são obrigados a esperar na fila até que um processo do servidor seja liberado. Além disso, ao tentar aumentar a contagem de processos filhos pré-fork, você facilmente consumirá alguma RAM séria.

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

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

Não use se: Seus módulos não quebrarão no encadeamento.

worker

mpm_workerusa threading - o que é uma grande ajuda para simultaneidade. Worker desativa alguns processos filho, que por sua vez desativam threads filho; 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, já que a contagem de threads não tem uma influência direta no uso da memória, como a contagem do servidor faz no prefork. Ele também lida com simultaneidade com muito mais facilidade, pois as conexões precisam apenas esperar por um thread livre (que geralmente está disponível) em vez de um servidor sobressalente no prefork.

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

Não use se: Você realmente não pode errar, a menos que precise de prefork 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 sempre mantém um thread até que seja fechado (o que pode levar muito tempo, dependendo da sua configuração). Por isso temos..

event

mpm_eventé muito semelhante ao trabalhador, estruturalmente; acabou de ser movido 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 vivas e transfere solicitações para encadeamentos filhos somente quando uma solicitação foi realmente feita (permitindo que esses encadeamentos sejam liberados imediatamente após a conclusão da solicitação). Isso é ótimo para a simultaneidade de clientes que não estão necessariamente todos ativos ao mesmo tempo, mas fazem solicitações ocasionais e quando os clientes podem ter um longo tempo limite de manutenção.

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

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

Não use se: Você não estiver no Apache 2.4 ou precisar de prefork para compatibilidade.

No mundo atual de slowloris , AJAX e navegadores que gostam de multiplexar 6 conexões TCP (com keep-alive, é claro) para seu servidor, a simultaneidade é um fator importante para fazer seu servidor dimensionar e dimensionar bem. A história do Apache o amarrou a esse respeito e, embora ainda não esteja à altura de nginx ou lighttpd em termos de uso ou escala de recursos, está claro que a equipe de desenvolvimento está trabalhando para construir um servidor web que ainda seja relevante no mundo de alta concorrência de hoje.

Aqui está uma boa explicação de como 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 (dispatcher) então sua escolha é um Event MPM

Em fevereiro de 2018, a documentação do Apache 2.4 para Event MPM afirma que usar o Apache como proxy impedirá que o "manuseio de conexão aprimorado" desde 2.4.24 funcione conforme projetado. Consulte 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 a resposta inteira seja vista antes de retornar o controle ao ouvinte.

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

Depende principalmente de quais módulos do Apache você deseja usar. Eu acho que o trabalhador geralmente é a escolha 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ê use a dependência preferida da distribuição do seu sistema operacional. O Ubuntu, por exemplo, instalará por padrão o mpm-worker quando você instalar o Apache2.