Forte Apache Resende

Configurando o Apache para rodar forte em ambiente de produção

A maioria dos servidores que vejo caindo não tem culpa do Apache em si. O problema é configuração genérica, módulos carregados à toa e quem manda colocar tudo no padrão sem ajustar nada. Sei disso porque já passei por isso na prática. No final de 2023, precisei resolver um caso onde um servidor com WordPress e um sistema interno de gestão travava nas horas de pico. A memória ia para 98%, o serviço respondia com 503, e ninguém sabia ao certo o que estava acontecendo. O diagnóstico foi rápido: o servidor estava usando o prefork MPM com 150 processos e cada processo consumia cerca de 40MB de RAM. Isso só funcionava se você tivesse 6GB dedicados, mas o plano era de 4GB. O que fiz foi trocar o MPM prefork pelo mpm_event, que é muito mais eficiente em concorrência. Mudei as configurações básicas de Limites, ajuste o KeepAliveTimeout para 5 segundos e defini o MaxKeepAliveRequests para 100. O servidor passou de travar a cada 30 minutos para ficar semanas sem problema. Depois disso, fiz um trabalho de limpeza nos módulos também. Desativei o mod_status, o mod_info e outros que não eram necessários. Cada módulo parado economiza memória e ciclos de processamento. Para quem está começando, o primeiro passo é sempre verificar qual versão do Apache está rodando. No Debian ou Ubuntu, o comando é simples: apachectl -v. Se estiver no CentOS ou RHEL, use httpd -v. Depois disso, olhe o MPM atual com apachectl -l. Isso já te dá uma noção do terreno.

O arquivo principal de configuração fica em /etc/apache2/apache2.conf no Debian/Ubuntu e em /etc/httpd/conf/httpd.conf no CentOS. Nele, você define os parâmetros globais. Um erro comum é deixar o Timeout padrão de 300 segundos. Para a maioria dos sites, 60 segundos já é mais do que suficiente. Requisições que não respondem nesse prazo provavelmente estão presas em algo pior do que simplesmente lento. Aqui vai algo que pouca gente considera: o valor de ServerLimit e ThreadLimit. Muitos tutoriais falam deles de forma genérica, mas na prática eles têm relação direta com o tamanho da sua máquina. Para um servidor com 8GB de RAM rodando PHP-FPM junto com o Apache, usei ThreadLimit 64 e ServerLimit 256. Para máquinas menores, esses números caem pela metade. Não adianta colocar valores altos só porque viu em algum artigo. A memória é o limitador real. Outro ponto importante é o uso do mod_deflate para compressão. Ativar gzip para HTML, CSS, JavaScript e JSON reduz o tempo de transferência em cerca de 60 a 70%. No arquivo de configuração, basta adicionar as diretivas para os tipos de arquivo certos. Mas cuidado com imagens JPEG e PNG, que já são comprimidas. Compactar de novo só perde tempo e ocupação de CPU.

Se o site tem muito tráfego de arquivos estáticos, considere configurar expires headers. Colocar expire_time de um ano para CSS, JS e fontes evita que o navegador do usuário faça requisição toda vez. Isso reduz o número de pedidos ao servidor e melhora a experiência do usuário. Quem usa certificados SSL precisa se preocupar com o HSTS e com os protocols corretos. Desative TLS 1.0 e TLS 1.1. O TLS 1.2 e 1.3 são suficientes hoje em dia. Configure o HSTS com max-age de pelo menos um ano. Isso força o navegador a usar HTTPS em todas as requisições futuras, o que ajuda na segurança e no SEO. Há uma limitação importante que poucos mencionam: o Apache não é a melhor escolha para aplicações que precisam de alta concorrência com muito uso de E/S. Se o seu sistema faz muitas leituras e escritas simultâneas em banco de dados, o Nginx ou o Caddy podem ser mais adequados. Use o Apache quando a configuração precisa ser flexível, quando você depende de .htaccess para regras dinâmicas, ou quando o ecossistema de módulos atende ao que você precisa.

Para aplicar as mudanças, após editar qualquer arquivo de configuração, rode apachectl configtest para validar se está tudo certo. Se retornar OK, reinicie com systemctl restart apache2 ou systemctl restart httpd, dependendo do sistema. Sempre verifique o status após o restart com systemctl status apache2. Logs de erro ficam em /var/log/apache2/error.log no Debian e em /var/log/httpd/error_log no CentOS. Uma dica prática que aprendi na mão: monitore o uso de memória com top ou htop enquanto o servidor está sob carga real. Nada substitui ver o que acontece de verdade. Simulações e testes locais nunca mostram exatamente o mesmo comportamento. Se o servidor estiver lento, olhe primeiro os logs antes de instalar qualquer ferramenta nova. Na maioria das vezes, o problema está na configuração e não na falta de recurso.