Preparar uma aplicação PHP para picos de tráfego não consiste em multiplicar o número habitual de visitas por um fator arbitrário. A capacidade necessária depende de quantas solicitações coincidem, quanto tempo cada uma demora e que trabalho executam: uma página em cache e uma operação que consulta vários serviços externos não consomem os mesmos recursos.
O objetivo operacional é saber qual componente limita o serviço sob uma carga representativa, quanta margem existe e o que fazer quando ela se esgota. Os testes fornecem evidências para tomar decisões; não garantem uma capacidade universal, porque o resultado depende do código, da infraestrutura, dos dados e do padrão real de uso.
Estime a carga por concorrência e por tipo de operação
O volume diário ou mensal é insuficiente para dimensionar. Uma aplicação pode receber muitas visitas distribuídas ao longo de horas e funcionar com folga, ou concentrar solicitações em poucos minutos e ficar saturada. Para estimar a pressão, observe a taxa de chegada, a duração das requisições e a proporção de operações concorrentes.
Como orientação, se a duração aumenta enquanto a taxa de chegada se mantém, mais solicitações permanecem ativas ao mesmo tempo. Por isso, uma dependência lenta pode elevar a concorrência mesmo que o tráfego de entrada não mude. O tráfego também pode ser desigual: uma campanha pode disparar páginas de produto e buscas, enquanto o fechamento de um período concentra autenticações, exportações ou gravações.
Comece identificando as rotas e operações que afetam os objetivos de negócio. Inclua, por exemplo, navegação pública, busca, início de sessão, criação de pedidos e tarefas administrativas relevantes. Diferencie leituras de gravações, requisições que podem ser armazenadas em cache das que não podem e solicitações síncronas de trabalhos que poderiam ser processados em uma fila. Não use a média global para ocultar uma rota lenta ou crítica.
Crie um teste representativo e seguro
Defina um ou mais cenários com base na telemetria disponível, nos registros de acesso e no calendário de eventos conhecidos. Documente qual proporção de solicitações corresponde a cada operação, como a taxa de chegada varia e quanto dura cada fase. É recomendável testar uma carga sustentada e um aumento rápido, pois eles revelam comportamentos distintos: esgotamento progressivo de recursos versus uma reação brusca a um pico.
O teste deve ser executado em um ambiente que represente a configuração de produção o suficiente para que seus resultados sejam úteis. Verifique diferenças no número de processos, limites de conexão, caches, tamanho dos dados e dependências. Se um teste for executado em uma máquina isolada com tabelas pequenas, isso não demonstra como a produção vai responder. Evite gerar carga contra usuários reais sem um plano e uma autorização explícitos.
Proteja os dados desde a concepção do cenário. Use dados sintéticos ou anonimizados, credenciais específicas e permissões mínimas; não copie dados pessoais para ferramentas de carga sem uma base e controles adequados. Evite que os testes enviem e-mails, cobrem pagamentos ou criem efeitos irreversíveis. Para operações externas, use ambientes de teste ou substitutos controlados, tendo em mente que um substituto não reproduz necessariamente a latência nem os limites do serviço real.
Meça latência, erros e saturação ao mesmo tempo
Registre a latência por rota e observe percentis, como p50, p95 e p99. A média pode permanecer estável enquanto parte das solicitações fica muito lenta; os percentis mostram melhor essa cauda. Meça também a taxa de erros, os tempos de espera e as solicitações concluídas por unidade de tempo. Um teste que gera muitas solicitações, mas também muitos erros, não comprova capacidade útil.
Relacione essas medidas aos recursos e às filas. No PHP, observe a ocupação e a fila dos processos que atendem às requisições, além de CPU, memória e reinicializações. Se você usa PHP-FPM, verifique a configuração e as métricas de seus processos e do servidor web; o nome do indicador disponível depende da instrumentação. No banco de dados, meça conexões ativas, espera para obter uma conexão, consultas lentas, bloqueios e uso de CPU ou disco. Observe também caches, filas e dependências externas.
Estabeleça limites associados à experiência e às operações, não apenas ao uso de CPU. Por exemplo, uma rota de compra pode exigir uma latência e uma taxa de erro máximas acordadas, enquanto uma exportação não crítica admite espera ou processamento assíncrono. Verifique se os relógios e as janelas de observação são comparáveis e se é possível associar um aumento de latência ao componente que ficou saturado.
Localize o primeiro gargalo antes de escalar
Procure o primeiro sinal que piora à medida que a carga aumenta gradualmente. Se a fila de processos web cresce e a CPU do PHP permanece alta, pode haver trabalho caro por requisição ou falta de processos disponíveis. Se os processos ficam esperando conexões, mas o banco de dados ainda tem capacidade, revise o limite do pool ou a configuração das conexões. Se o banco de dados apresenta consultas lentas, bloqueios ou saturação, adicionar processos PHP pode aumentar a pressão e piorar o problema.
As dependências externas também podem manter processos ocupados. Verifique os tempos de conexão e resposta, os limites de taxa e o comportamento em caso de erros. Um tempo limite longo demais mantém recursos ocupados; tentar novamente sem limite pode multiplicar a carga. Defina tempos limite restritos e uma política de novas tentativas seletiva, com espera progressiva quando apropriado, e evite repetir automaticamente operações não idempotentes sem proteção.
Diferencie falta de capacidade de ineficiência. Uma consulta que percorre linhas demais, chamadas repetidas ao mesmo serviço ou cálculos redundantes continuarão custando caro mesmo com a adição de servidores. Faça o profiling de rotas representativas e reduza o trabalho por solicitação: otimize consultas e índices com base em evidências, limite os resultados, elimine chamadas desnecessárias e use cache quando a consistência e a privacidade permitirem. Em seguida, repita o teste para verificar se a melhoria se mantém sob carga.
Intervenha em ordem e planeje degradações controladas
Primeiro, reduza o custo do trabalho por solicitação e corrija as consultas ou dependências que atuam como limite. Depois, revise os limites de concorrência, os processos web e os pools de conexões. Aumentar o número de processos pode melhorar o paralelismo até que CPU, memória ou banco de dados fiquem saturados; configurar mais conexões do que o banco de dados consegue atender apenas transfere a fila. Altere uma variável por vez e meça novamente.
O escalonamento vertical — mais recursos em uma instância — pode ser uma intervenção simples se o componente puder crescer e não houver um limite estrutural. O horizontal — mais instâncias — exige que a implantação, as sessões, os arquivos, as tarefas e o banco de dados suportem essa distribuição. Verifique o balanceamento, o armazenamento compartilhado ou externo quando aplicável, a saúde das instâncias e os limites comuns, como conexões com o banco de dados. Nenhuma opção corrige, por si só, uma consulta ineficiente.
Defina o que preservar quando a capacidade for escassa. Priorize autenticação, operações essenciais ou confirmações de transação de acordo com o produto; adie relatórios, limite buscas caras ou desative temporariamente funções dispensáveis. Use filas para trabalhos que possam ser concluídos depois e comunique o status ao usuário. Aplique limites de taxa ou respostas de sobrecarga de forma explícita, com mecanismos prudentes de nova tentativa. Uma degradação controlada deve evitar a perda de operações confirmadas e oferecer uma alternativa compreensível, não retornar um sucesso fictício.
Para transformar os testes em uma decisão operacional, mantenha um registro com o cenário, a configuração, os resultados por rota, o primeiro limite observado, as alterações feitas e o critério de aceitação. Repita o teste após modificar código, infraestrutura, dados ou dependências relevantes. Antes de um pico previsto, confirme os alertas, a capacidade disponível, os procedimentos de reversão e os responsáveis pelas decisões.
Lista de verificação antes de um pico
- Cenário: reflete rotas, proporções, ritmo e duração plausíveis; inclui uma subida rápida e uma carga sustentada.
- Segurança: usa dados e credenciais adequados, evita efeitos reais indesejados e controla o destino do teste.
- Observabilidade: correlaciona latência p95/p99, erros e throughput com processos PHP, banco de dados, cache e dependências.
- Diagnóstico: identifica o primeiro limite e confirma se ele se deve à saturação, a consultas, à concorrência ou a esperas externas.
- Alteração: modifica uma causa por vez, compara os resultados e verifica se a saturação não foi transferida para outra camada.
- Resiliência: define limites, prioridades, degradações, comunicação e recuperação sem perder operações confirmadas.
- Repetição: estabelece critérios de aceitação e testa novamente após alterações importantes e antes de eventos previsíveis.
Dimensionar com rigor significa conhecer a resposta da aplicação a cenários concretos e decidir com margem, não perseguir um número abstrato de usuários. As medições mostram onde investir: otimização, ajuste da concorrência, capacidade adicional ou uma política de degradação que mantenha úteis as funções essenciais.
