Análise de impacto da utilização de diferentes módulos de
multiprocessamento em um servidor Web
Em um mundo cada dia mais dinâmico, nada pior do que ter que esperar as coisas. Isso
tem que ser levado muito em conta quando se trata de sites na Internet, principalmente os
que vendem online. Esse é o motivo pelo qual você deve se preocupar, e muito, com a
performance do seu site.
De acordo com a Forrester Consulting, em 2006, compradores online esperavam que uma
página web carregasse em até 4 segundos e, hoje, esse mesmo cliente espera que essa
página carregue em 2 segundos ou menos. A Amazon, pouco tempo atrás, descobriu que
aumentou sua receita em 1% a cada 100 milisegundos de ganho em performance, e um
estudo comprovou que cada segundo gasto na abertura de uma página pode representar
5% a menos de conversão para a sua loja.
O Apache, hoje, é o webserver mais utilizado do mundo, usado por cerca de 60% dos
sites, com suporte para todos os sistemas operacionais e centenas de módulos
disponíveis. Além disso, é um servidor muito estável e open source.
Quando se trata de Apache, a memória é o recurso mais importante para ele. Mensurar
mal a quantidade de memória que será utilizada pode significar usar a swap, ou seja,
muitos processos para pouca memória, ou gerar uma lentidão no sistema, que acontece
quando se tem poucos processos e muita memória sobrando. Dessa forma, a memória
tem que ser muito bem mensurada para não se ter nenhum tipo de problemas.
Outra coisa que pode ajudar muito quando se trata de Apache é o uso de MPM (Multiprocessing Modules), que são responsáveis por manipular as requisições
concorrentemente e a escolha certa desses módulos pode fazer grande diferença na
performance, escalabilidade, consumo de memória e consumo de CPU do seus sistema.
Os MPMs mais comuns hoje são:
Worker
A outra opção de MPM, o worker, trabalha com o conceito multi-thread, onde as requisições
são atendidas por threads e não por processos. Assim, teríamos apenas um ou poucos
processos com múltiplas threads em cada um deles, atendendo cada uma das conexões. Com
o worker, minimizamos a utlização de memória, já que as threads compartilham a mesma
área de memória do processo pai, e reduzimos o overhead na criação de processos. Na
verdade, no caso do worker, definimos a quantidade de threads por processo de modo que só
realizamos um fork quando este limite é atingido.Porém, ele é menos estável, muito difícil
de debugar, tem problemas ao trabalhar com módulos não thread-safe e, se algum
problema acontecer na thread, esse problema pode influenciar no processo pai.
Prefork
Neste módulo, cada request é tratado por um processo separado e, dessa forma, um
problema no processo filho não implica no processo pai. É muito tolerante a falhas e, por
causa disso, muito estável e pode ser utilizado com módulos não thread-safe. Falando
pelo lado do desenvolvedor, ele é ideal para módulos monolíticos (PHP), muito fácil de
debugar e efetua pooling de processos. Mas, como nem tudo são flores, ele utiliza mais
memória do que o Worker e criar um processo nele é muito custoso e demorado.
Basicamente, no prefork, para cada conexão será criado um processo específico para atendêla, de modo que a quantidade de processos httpd será sempre maior ou igual a quantidade de
clientes. Nesta arquitetura, temos uma quantidade inicial que processos que são pré-criados
para atender as conexões, sendo que a medida que os clientes se conectam, eles são
atendidos por estes processos. No prefork, temos basicamente dois problemas em termos de
performance:
•
Memória: cada processo criado ocupa uma porção da memória, de modo que a memória
disponível para cache do kernel é cada vez menor, ao ponto que toda ela é preenchida
pelos processos httpd, momento onde o servidor começa a fazer swap em disco;
•
Load: a criação de novos processos (fork) gera um overhead no sistema, de modo que
quanto maior a taxa de conexão, maior será o overhead no fork para atender as novas
conexões;
Dessa forma, você deve analisar o seguinte antes de implementar algum deles: Prefork é
mais estável; Worker requer menos hardware.
Escolha
A escolha entre prefork ou worker deve ser realizada caso a caso, ou seja, dependendo da
situação de uso e da configuração de hardware uma escolha poderá ser melhor que a outra.
Para o perfil do site www.bazar.projetointegrador.com , levando-se em consideração que o
objetivo do projeto seja alcançar maiores quantidades de acesso, não se delimitando somente
a faculdade mas buscando acesso das mais variadas regiões, consolidando o sucesso do
projeto. A melhor solução seria o uso do módulo PREFORK devido a sua tolerância a falhas,
tornando o website mais estável e a facilidade para se debugar e efetuar pooling de
processos. Porém as configurações do nosso servidor de hospedagem teria que ter Hardware
mais robusto, sendo a memória o recurso mais importante a ser observado.