Teste de carga do site antes do lançamento
O teste de carga responde quantos visitantes o site aguenta no servidor escolhido e o que quebra primeiro. Ele é feito no seu próprio servidor e só nele: o gerador de carga roda em outra máquina, o provedor é avisado e os serviços externos são substituídos por stubs. Veja quais números acompanhar, com quais programas obtê-los e como usá-los para escolher o plano.
Um site que abre rápido na máquina do desenvolvedor pode parar de responder quando cem pessoas chegam ao mesmo tempo: acabam os processos PHP, as conexões com o banco de dados ou a memória. Descobrir isso no dia de uma campanha de publicidade sai mais caro do que uma semana antes. O teste de carga reproduz o fluxo de visitantes no seu servidor e mostra onde está o limite e quanto falta até ele.
O que medir
O resultado do teste não é um número só, mas um conjunto de indicadores que se analisam juntos:
- RPS (requisições por segundo): quantas requisições o servidor processa. Sozinho, o RPS diz pouco: o servidor pode responder a mil requisições por segundo, mas cada resposta levar cinco segundos.
- Tempo de resposta por percentis: p95 significa que 95% das requisições ficaram dentro desse tempo, e p99, que 99% ficaram. A média esconde as respostas lentas: se 90 requisições levaram 100 ms e 10 levaram 3 segundos, a média de cerca de 400 ms parece aceitável, embora um em cada dez visitantes espere três segundos.
- Taxa de erros: respostas 5xx, conexões interrompidas e timeouts. Sob carga, os erros costumam aparecer antes de o tempo de resposta crescer de forma perceptível.
- Recursos do servidor: uso do processador, memória livre e swap, espera de disco (iowait), número de conexões com o banco. Esses dados são coletados no próprio servidor durante o teste; sem eles, não dá para saber em que o site esbarrou.
A meta é definida antes, nas mesmas unidades: por exemplo, «com 50 requisições por segundo, p95 da página inicial e do catálogo abaixo de 500 ms e menos de 1% de erros». Sem meta, o teste vira um monte de gráficos que não ajudam a decidir nada.
Tipos de teste
- Smoke test: alguns usuários virtuais durante um minuto. Confirma que o cenário foi escrito corretamente e dá o tempo de resposta de referência, sem carga.
- Teste de carga: o pico de tráfego esperado durante 15–30 minutos. Responde se o servidor dá conta da carga planejada.
- Teste de estresse: a carga sobe em degraus até os erros ou o tempo de resposta aumentarem. Mostra o limite e como o site se comporta além dele: se devolve um erro rápido ou trava.
- Teste de longa duração: carga moderada por várias horas. Encontra vazamentos de memória, logs e disco enchendo, conexões que se acumulam.
O cenário deve se parecer com visitantes reais: uma mistura de páginas (inicial, catálogo, página de produto, busca), pausas entre as ações e uma parte dos usuários logada ou com carrinho. Um teste que pede mil vezes por segundo a mesma página em cache mede o cache, e não o site.
Ferramentas
Os quatro programas abaixo são gratuitos e rodam pela linha de comando. Os dois primeiros servem para cenários com várias páginas; os dois últimos, para uma verificação rápida de um único endereço.
- k6: os cenários são escritos em JavaScript, e o resultado já sai com percentis. No cenário você define limites: segundo a documentação do k6, condições como
http_req_failed: ['rate<0.01']ehttp_req_duration: ['p(95)<200']são verificadas ao fim do teste, e, se alguma for violada, o k6 termina com código de saída diferente de zero. Por isso é fácil incluir o k6 no CI: um build que deixou o site mais lento não passa. - Apache JMeter: os cenários são montados numa interface gráfica, com formulários, login, análise das respostas e dados de arquivos CSV. Já o teste em si deve ser executado no modo de linha de comando, com
jmeter -n -t test.jmx -l test.jtl: o modo gráfico consome recursos do gerador e distorce o resultado. - wrk: um gerador multithread que, a partir de uma única máquina, cria uma carga alta sobre um endereço. Exemplo:
wrk -t4 -c100 -d60s --latency https://example.com/, com 4 threads, 100 conexões, um minuto e a distribuição das latências. Cenários mais complexos são escritos em Lua. - ab (ApacheBench): a opção mais simples, muitas vezes já instalada junto com o Apache. A documentação diz claramente que o ab não implementa o HTTP/1.x por completo e, sob carga alta, pode medir a própria velocidade, e não a do servidor. O keep-alive vem desligado por padrão e é ativado com a opção
-k. Serve para uma checagem rápida, mas não para decidir o plano.
Como testar sem atrapalhar ninguém
O teste de carga gera o mesmo fluxo de requisições que uma onda de visitantes, por isso só pode ser feito num servidor que você administra e respeitando as regras da plataforma onde ele está.
- Só o seu servidor e o seu domínio. Aplicar carga a sites e APIs de terceiros sem a autorização por escrito do dono é inaceitável, mesmo que seja «só por um minuto». Se o site chama um gateway de pagamento, uma transportadora ou uma API externa, durante o teste esses serviços são substituídos por stubs ou pelos ambientes de teste desses próprios serviços.
- Avise o provedor. A proteção contra DDoS do provedor pode tomar o teste por um ataque e bloquear o endereço do gerador, e as regras de alguns provedores exigem que esse tipo de teste seja combinado antes. Por exemplo, a política da AWS permite testes de estresse dos seus próprios serviços preparados para isso, mas proíbe a simulação de ataques DDoS. Um e-mail curto ao suporte com data, horário, endereços e volume esperado resolve a questão. Como funciona a proteção nos provedores está no artigo Proteção contra DDoS: o que os provedores realmente oferecem.
- Não na hospedagem compartilhada. Num servidor compartilhado, o teste deixa os vizinhos mais lentos, e o resultado depende deles. O teste é feito numa VPS ou num servidor dedicado, onde os recursos são reservados para você.
- O gerador fica em outra máquina. Se rodar no mesmo servidor, ele toma o processador do site. Para o gerador, uma VPS com cobrança por hora é prática: ela é criada para o teste e apagada em seguida. Pelo catálogo da accsly.io (novembro de 2026), a cobrança por hora aparece de forma explícita em 173 dos 2.247 provedores de VPS; os planos estão reunidos na página VPS com cobrança por hora.
- Lembre-se do tráfego. Uma hora de teste pode transferir centenas de gigabytes. Se o plano tem tráfego limitado ou a banda é dividida com vizinhos, o excedente é cobrado ou a velocidade é reduzida; mais detalhes no artigo Banda e tráfego: o que significam 1 Gbit/s e ilimitado.
- CDN e proteção na frente do site. Se o domínio está ligado a uma CDN, um teste por ela avalia a CDN e pode esbarrar nos limites dela. O servidor de origem é testado diretamente pelo seu endereço, e a carga através da CDN é combinada com o provedor da CDN.
Como ler o resultado e escolher o plano
Quando a carga sobe em degraus, o RPS primeiro cresce junto com ela, e o tempo de resposta quase não muda. Depois vem o ponto de saturação: o RPS para de crescer, o p95 dispara e surgem erros. A carga de trabalho deve ficar bem abaixo desse ponto: a margem cobre picos, tarefas em segundo plano e o crescimento do público. Uma referência prática é que o pico esperado ocupe no máximo metade do limite encontrado.
Em seguida, veja em que o servidor esbarrou no ponto de saturação:
- processador em 100%: são necessários mais núcleos ou uma frequência mais alta, se o gargalo estiver numa única thread; os planos com frequência a partir de 4 GHz estão na página VPS com processador de alta frequência;
- a memória acabou e o servidor passou a usar swap: é preciso mais memória ou menos processos PHP-FPM e workers; referências de volume no artigo Quanta memória e quantos núcleos um site precisa;
- iowait alto: o disco não dá conta, geralmente por causa do banco de dados; ajudam o NVMe e os índices, e a comparação está no artigo NVMe ou SSD: faz diferença para um site?;
- recursos livres, mas com erros: o limite está nas configurações, como o limite de conexões do banco, o número de workers do servidor web ou de arquivos abertos.
Antes de contratar, vale repetir o teste no plano que você pretende levar: processadores e discos variam entre provedores mais do que os números da descrição deixam ver. O mais prático é fazer isso com cobrança por hora ou no período de teste, como descrito no artigo Como testar ping e velocidade de uma VPS antes de pagar. Depois do lançamento, os mesmos indicadores (tempo de resposta, erros, uso de recursos) passam para o monitoramento, para que o aumento da carga fique visível antes de o site começar a responder com erros.