Olá,
Inicio este artigo definindo a palavra tuning, quando se fala em tecnologia da informação, como a otimização de recursos computacionais com a finalidade de se extrair o máximo do hardware, software, daemon, etc.
No artigo de hoje vamos otimizar o Apache 2.4.x com o módulo de multiprocessamento chamado PREFORK. Nós temos quatro: PREFORK, ITK, WORKER, EVENT (para o Unix).
Esses MPMs causam diferentes impactos no modo de trabalho do servidor e, principalmente, nos recursos de hardware (memória RAM e processador) necessários para atender as requisições HTTP ou HTTPS.
O método PREFORK é o mais utilizado entre os sysadmins por conta de sua estabilidade e alta compatibilidade com os mais diversos hardwares e sistemas, no entanto, para aplicações de grande porte, não é o mais indicado.
Este artigo é para você que possui uma aplicação de uma startup que está começando agora e deseja realizar um tuning no Apache sem muitas complicações e com o MPM default que é o prefork. Se formos gerar um de x para sobre os MPMs, temos:
Aplicações de pequeno porte -> PREFORK e ITK
Aplicações de médio porte -> WORKER
Aplicações de grande porte -> EVENT
No Ubuntu 14.04, por exemplo, ao instalar o apache2 de forma default, o prefork é instalado, vejamos:
[php]
root@rodrigocalado:/home/ubuntu# dpkg –get-selections | grep apache
apache2 install
apache2-bin install
apache2-data install
apache2-mpm-prefork install
root@rodrigocalado:/home/ubuntu#
[/php]
Como vamos fazer o tuning baseado no prefork, é bom vocês saberem que o uso de memória SWAP é até 100x mais lento que o uso de memória RAM, portanto vamos fazer algo que não seja necessário utilizar a memória SWAP.
Supondo que estejamos tratando de um servidor com 4096 MB de RAM e o sistema consuma 800 MB de RAM com o apache desligado, então temos apenas 3296 MB disponíveis para o tuning.
Agora vem a parte que é crucial para este artigo, pois cada aplicação vai consumir um número específico de MB de memória RAM por usuário (processo filho do Apache). Existem páginas de html puro que consomem 5 MB, phps que consomem 20 MB, 250 MB ou até mais, a depender se o código está otimizado. Já utilizei relatórios que consumiam 1 GB de RAM, ou seja, é muito relativo e vai depender muito do programador. Esta é a parte em que falo que a equipe de desenvolvimento possui responsabilidade, na mesma medida, que a equipe de infraestrutura no desempenho de uma aplicação. São equipes que devem trabalhar juntas. Uma forma meio “workaround” que encontrei pra saber se a sua aplicação é otimizada e consome 20 MB de memória RAM sem gerar “Fatal error: Allowed memory size of x bytes exhausted” é:
[php]ini_set(‘memory_limit’,’20M’);[/php]
Se você setar este init_set em toda a sua aplicação e ela não gerar erro, então você poderá utilizar o valor 20 MB para ser dividido pelo número 3296 acima cujo total é 165.
O número 165 deve ser aplicado no MaxClients e/ou MaxRequestWorkers do seu Apache.
Utilizar de 1 a 5 segundos no KeepAliveTimeout para evitar que os processos fiquem inertes, caso um usuário abandone o site. O KeepAlive deve ficar ligado para garantir que, se o usuário continuar navegando em teu site com interações rápidas entre 1 e 5 segundos, não seja necessária abrir uma nova thread para atendê-lo.
Este servidor que acabei de citar pode suportar até 165 conexões simultâneas com scripts em PHP otimizados para, no máximo, 20 MB de uso de memória por cada página.
Agora Rodrigo, como vou saber a quantidade de conexões simultâneas de meu site ou aplicação? O método mais simples é você implementar o Google Analytics e utilizar a opção “Real-Time -> Overview”. Vejamos uma imagem que tirei agora de um site qualquer:
Considerando que estou com 36 usuários ativos neste site, então o servidor de 4GB de memória vai conseguir suportá-lo nas condições de scripts em PHP otimizados para ocupação máxima de 20 MB por execução.
Abs a todos,
