Como eu seleciono qual Apache MPM usar?

245

This is a Canonical Question about selecting the right Apache httpd MPM.

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 deles será melhor para uma determinada implantação?

    
por Tiffany Walker 26.04.2012 / 20:40

4 respostas

398

Existem vários módulos MPM (Módulos de multi-processamento), mas de longe o mais amplamente utilizados (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 do tempo ao longo de seu longo histórico (em termos de software).

prefork

mpm_prefork é .. bem .. é compatível com tudo. Ele gera vários processos filhos para atender a solicitações, e os processos filhos só atendem a uma solicitação de cada vez. Porque ele tem o processo do servidor parado, pronto para a ação, e não precisando lidar com o empacotamento de threads, é realmente mais rápido do que os MPMs mais modernos quando você está lidando apenas com um único pedido em um tempo - mas as solicitações simultâneas sofrem, pois elas são obrigadas a esperar na fila até que um processo do servidor esteja livre. Além disso, tentando escalar na contagem de processos filho pré-fabricados, você vai facilmente sugar algumas RAMs graves.

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

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

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

worker

mpm_worker usa segmentação - o que é uma grande ajuda para a simultaneidade. Trabalhador faz alguns processos filhos, que por sua vez geram segmentos filhos; semelhante ao prefork, alguns threads sobressalentes são mantidos prontos, se possível, para atender conexões de entrada. Essa abordagem é muito mais gentil com a RAM, já que a contagem de threads não tem um impacto direto no uso de memória, como ocorre com a contagem de servidores no prefork. Ele também lida com a simultaneidade com muito mais facilidade, já que as conexões precisam esperar por um encadeamento livre (que geralmente está disponível) em vez de um servidor reserva no prefork.

Use if: 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 compatibilidade com o prefork.

No entanto, observe que os passos estão ligados a conexões e não solicitações - o que significa que uma conexão keep-alive sempre mantém um segmento até que ele seja fechado ( que pode ser um longo tempo, dependendo da sua configuração). É por isso que 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 ativas, e entrega os pedidos para os encadeamentos filhos somente quando uma solicitação foi realmente feita (permitindo que esses encadeamentos sejam restaurados imediatamente após a conclusão da solicitação). Isso é ótimo para a simultaneidade de clientes que não são necessariamente todos ativos por vez, mas fazem solicitações ocasionais e quando os clientes podem ter um longo tempo de espera de manutenção.

A exceção aqui é com conexões SSL; nesse caso, ele se comporta de maneira idêntica ao worker (colando uma determinada conexão a um determinado thread 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 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 compatibilidade com o prefork.

No mundo de hoje de slowloris , AJAX e navegadores que Como o multiplex 6 conexões TCP (com keep-alive, é claro) para o seu servidor, a simultaneidade é um fator importante para tornar a escala do seu servidor e escalar bem. A história do Apache o atrelou a esse respeito e, embora ainda não esteja de acordo com os gostos do nginx ou lighttpd em termos de uso de recursos ou escala, fica claro que a equipe de desenvolvimento está trabalhando na construção de um servidor da Web ainda relevante no mundo atual de alta solicitação de concorrência.

    
por 27.04.2012 / 04:27
5

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

Se você não tem preferências, eu recomendo que você vá com a dependência preferida de sua distribuição do sistema operacional. O Ubuntu, por exemplo, instalará por padrão o mpm-worker quando você instalar o Apache2.

    
por 26.04.2012 / 21:32
5

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

link

Resumidamente: se você estiver no 2.4 e precisar do httpd como um proxy reverso (despachante), sua escolha será Event MPM

    
por 21.06.2017 / 15:10
3

Em fevereiro de 2018, a documentação do Apache 2.4 para o Event MPM afirma que o uso do Apache como proxy manterá o "melhor gerenciamento de conexão" desde que o 2.4.24 funcione como projetado. Consulte a seção Limitações .

A questão é que, como um proxy, o trabalhador não pode dizer onde está o fim 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 o uso do modelo Worker pode ser melhor quando o apache é usado como um proxy. Não está claro para mim se existem vantagens para o modelo de evento em um ambiente de proxy, mas talvez existam.

    
por 14.02.2018 / 16:01