Apache Performance Tuning: Módulos MPM

por
  1. Ajuste do Desempenho do Apache: Memória de troca
  2. Afinamento do desempenho do Apache: Módulos MPM
  3. Ajuste do Desempenho do Apache: Directivas MPM
  4. Ajustamento do Desempenho do Apache: Configurando Diretivas MPM
  5. Como Habilitar Logging Piped no Apache

Tempo de Leitura: 3 minutos

A pedra-chave para entender o desempenho do servidor Apache é de longe os Módulos de Multiprocessamento (MPMs). Estes módulos determinam a base de como o Apache aborda o multiprocessamento. Multiprocessamento significa executar múltiplas operações simultaneamente em um sistema com múltiplas unidades centrais de processamento (CPU Cores).

Existem muitos MPMs para escolher; no entanto, este artigo foca nos módulos mais comumente utilizados em servidores VPS baseados no Liquid Web Linux. Estes módulos são:

  • MPM Prefork
  • MPM Worker
  • MPM Event
  • Outros MPMs
  • Qual é o melhor MPM?

MPM Prefork

O MPM Prefork auto-regulador deriva o seu nome da forma como se bifurca ou copia a si próprio em novos processos idênticos de forma preemptiva para esperar pelos pedidos recebidos. Uma abordagem não baseada em processos de multiprocessamento, o MPM Prefork executa o Apache em um único processo do servidor principal. Este pai é responsável pelo gerenciamento de qualquer servidor filho adicional que compõe seu serverpool. Enquanto utiliza o MPM Prefork, cada servidor filho lida apenas com uma única requisição. Este foco fornece completo isolamento de outras requisições tratadas no servidor. O MPM Prefork é tipicamente usado para compatibilidade quando bibliotecas/software sem threads, como mod_php (DSO), são necessários. Do ponto de vista da otimização, o MPM Prefork pode ser muito carente quando comparado com soluções multithreaded, exigindo muito mais recursos para atingir níveis de tráfego similares aos de um MPM com threads. É de recursos intensivos devido à sua necessidade de gerar cópias completas do Apache para cada pedido.

Nota:
Evite usar o MPM Prefork sempre que possível. É incapacidade de escalar bem com o aumento do tráfego irá rapidamente ultrapassar o hardware disponível na maioria das configurações do sistema.

M Worker

Um servidor web híbrido de pré-forking, multi threaded, multiprocessamento. Da mesma forma que o MPM Prefork, o MPM Worker utiliza a mesma abordagem com um único processo de master parent que rege todas as crianças dentro do seu pool de servidores. No entanto, ao contrário do MPM Prefork, estas crianças são processos multi-tarefa que podem lidar com dezenas de threads (pedidos) simultaneamente. O MPM Worker estabeleceu a base para multiprocessamento de múltiplos threads em servidores Apache que se tornaram estáveis no Apache 2.2. A configuração com threads permite ao Apache atender centenas de pedidos com facilidade enquanto mantém apenas uma dúzia de processos filhos na memória. O MPM Worker faz tanto uma solução de alta capacidade quanto de baixo recurso para web service.

Nota
A diretiva KeepAliveTimeOut atualmente define a quantidade de tempo que o Apache esperará pelos pedidos. Ao utilizar o KeepAlive com MPM Worker use o menor KeepAliveTimeout possível (1 segundo de preferência).

>

MM Event

Baseado no código fonte do MPM Worker, o MPM Event compartilha as diretrizes de configuração com o MPM Worker. Ele funciona quase idêntico ao MPM Worker, exceto quando se trata de lidar com pedidos do KeepAlive. O MPM Event usa um thread Listener dedicado em cada processo infantil. Esta thread de Listening é responsável por direcionar as solicitações de entrada para uma thread de trabalhador disponível. O tópico de escuta resolve o problema encontrado pelo MPM Worker, o qual bloqueia tópicos inteiros na espera pelo KeepAliveTimeout. A abordagem de escuta do evento MPM garante que as roscas do trabalhador não fiquem “presas” à espera que o KeepAliveTimeout expire. Este método mantém a quantidade máxima de threads de operários que manipulam o maior número possível de pedidos.

Informação de limite de servidor

Dica:
O evento MPM é estável no Apache 2.4, versões anteriores podem usar o MPM Worker como alternativa.

Outros MPMs

Existe um sortimento de MPMs adicionais disponíveis. Estes são tipicamente parte da integração do Apache em Sistemas Operacionais que não sejam sistemas baseados em Unix. Estes têm MPMs específicos que são requisitos ou utilizam o Apache em seus respectivos tipos de sistemas. Estes tipos de MPMs estão além do âmbito deste artigo. Você pode encontrar mais informações sobre MPMs específicos na seção MPM Defaults da Documentação oficial do Apache.

Note:
Recomendamos ficar longe dos MPMs experimentais e instáveis. A natureza não confiável desses tipos de software os torna insuportáveis.

Qual MPM é o Melhor?

Ao considerar a otimização, é essencial entender que não existe uma configuração Apache de tamanho único. Escolher corretamente um MPM requer a análise de muitas variáveis móveis como tráfego, código do site, tipo de servidor, PHP Handler e hardware disponível. Cada servidor é único tornando o melhor MPM uma escolha inteiramente subjetiva.

Se o código da sua aplicação não suporta multi-tarefa, então sua escolha será inevitavelmente o MPM Prefork puramente com base na compatibilidade. O MPM Prefork inclui módulos de software como o mod_php (DSO). O MPM Worker sem o KeepAlive funciona muito bem se a sua aplicação for um sistema API balanceado de carga de alto desempenho. A escalabilidade e flexibilidade do MPM Event é uma escolha sólida para hospedar vários sites pequenos e médios em uma configuração de hospedagem compartilhada.

Mais simples configurações de servidores operam bem sob a configuração padrão auto-governada do MPM Event, tornando-o um ponto de partida ideal para o ajuste de otimização. Uma vez escolhido, um MPM pode então passar para as Diretivas de Configuração para rever quais configurações dizem respeito ao desempenho e otimização do servidor. Ou confira nosso artigo anterior nesta série, Apache Performance Tuning: Swap Memory.

Navegação em série << Artigo anteriorArtigoArtigo seguinte >>

Deixe um comentário