Apache 2.4 - Módulos de Multiprocessamento - MPM
Com a versão 2.4 no Debian Jessie, a MPM event entrou em estado de produção. Neste artigo, vamos diferenciar "prefork", "worker" e "event" para entender um pouco mais seu funcionamento. As informações são baseadas no manual do Apache 2.4.
Parte 4: MPM event
Esse MPM é uma variante de worker, elaborada para permitir mais requisições simultâneas utilizando intensamente os threads. Vejamos como isso funciona na prática.
Esse MPM tenta solucionar o problema keep alive presente no servidor HTTPD. Um cliente HTTP sempre tenta manter a conexão aberta e enviar mais requisições pelo mesmo socket. Isso representa uma sobrecarga para TCP que gerencia a abertura e o fechamento das conexões. Tradicionalmente, a abordagem utilizada por Apache é manter um processo filho e seus threads aguardando por novas requisições o que representa desvantagens óbvias.
Para tentar solucionar essa questão, a MPM event realiza uma abordagem diferente utilizando um thread dedicado para manipular os sockets, que ouvem por conexões, ao mesmo tempo que utiliza outros threads para enviar e receber dados de conexões já estabelecidas.
Para alguns casos de uso, alguns filtros se declaram incompatíveis com event e voltam a se comportar como se estivessem sendo utilizados por worker, reservando um thread por conexão. Todos os módulos providos juntamente com Apache são compatíveis com event.
Observe que muitas das diretivas de worker são válidas também para event.
AsyncRequestWorkerFactor - limita o número de conexões concorrentes por processo. A MPM event manipula algumas conexões de modo assíncrono. Requisições que trabalham com threads são alocadas por um período de tempo curto, conforme necessário, e outras requisições com um thread reservado por conexão. Isso pode levar a situação onde todos os workers estão ocupados e não há threads disponíveis para manipular novas solicitações assíncronas de conexão.
Para mitigar esse problema, event faz duas coisas. Inicialmente, ele limita o número de conexões aceitas por processo, dependendo do número de workers idle. Posteriormente, se todos os workers estão ocupados, ele fechará conexões que estão no estado keep alive mesmo se o timeout não tenha sido atingido.
Essa diretiva permite um ajuste mais fino (tunning) do limite das conexões por processo. Um processo somente aceitará novas conexões se o número de conexões correntes ( conexões em estado closing não são contadas) for menor que:
Isso significa que o número máximo de conexões concorrentes é:
Esse MPM tenta solucionar o problema keep alive presente no servidor HTTPD. Um cliente HTTP sempre tenta manter a conexão aberta e enviar mais requisições pelo mesmo socket. Isso representa uma sobrecarga para TCP que gerencia a abertura e o fechamento das conexões. Tradicionalmente, a abordagem utilizada por Apache é manter um processo filho e seus threads aguardando por novas requisições o que representa desvantagens óbvias.
Para tentar solucionar essa questão, a MPM event realiza uma abordagem diferente utilizando um thread dedicado para manipular os sockets, que ouvem por conexões, ao mesmo tempo que utiliza outros threads para enviar e receber dados de conexões já estabelecidas.
Para alguns casos de uso, alguns filtros se declaram incompatíveis com event e voltam a se comportar como se estivessem sendo utilizados por worker, reservando um thread por conexão. Todos os módulos providos juntamente com Apache são compatíveis com event.
Observe que muitas das diretivas de worker são válidas também para event.
AsyncRequestWorkerFactor - limita o número de conexões concorrentes por processo. A MPM event manipula algumas conexões de modo assíncrono. Requisições que trabalham com threads são alocadas por um período de tempo curto, conforme necessário, e outras requisições com um thread reservado por conexão. Isso pode levar a situação onde todos os workers estão ocupados e não há threads disponíveis para manipular novas solicitações assíncronas de conexão.
Para mitigar esse problema, event faz duas coisas. Inicialmente, ele limita o número de conexões aceitas por processo, dependendo do número de workers idle. Posteriormente, se todos os workers estão ocupados, ele fechará conexões que estão no estado keep alive mesmo se o timeout não tenha sido atingido.
Essa diretiva permite um ajuste mais fino (tunning) do limite das conexões por processo. Um processo somente aceitará novas conexões se o número de conexões correntes ( conexões em estado closing não são contadas) for menor que:
- ThreadsPerChild + (AsyncRequestWorkerFactor * número de idle workers)
Isso significa que o número máximo de conexões concorrentes é:
- (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers