Quantos acessos simultâneos sua VPS aguenta: como medir com teste de carga antes do pico

O número de acessos simultâneos que uma VPS aguenta não vem do plano de hospedagem: vem de um teste de carga que simula visitantes na sua própria loja até o tempo de resposta disparar.

Quantos acessos simultâneos a minha VPS aguenta de verdade?

Quantos acessos simultâneos a sua VPS aguenta não é um número de tabela. O teto depende do trabalho que cada visita gera na sua loja — quantas consultas ao banco, quanto PHP executado, quanto sai do cache — e só aparece medindo. A medição se chama teste de carga: um programa simula muitos visitantes pedindo páginas ao mesmo tempo, e você observa a que altura o site começa a engasgar.

O “suporta X visitas por mês” do plano de hospedagem não responde a essa pergunta. É número de contrato, e mede volume espalhado em trinta dias. O mesmo total mensal concentrado em duas horas de campanha é outro problema.

Duas lojas na mesma VPS, uma com cache de página ligado e outra sem, aguentam volumes diferentes. Mesmo hardware, tetos diferentes. É por isso que copiar o número do vizinho não serve.

O teto existe mesmo sem ninguém medir — você só descobre onde ele fica quando estoura, em plena campanha, com o carrinho cheio na tela do cliente. O que sai deste artigo é o contrário disso: um número próprio, obtido em teste, que dá para comparar com o pico real da sua loja antes da data.

O que medir: usuário virtual, requisição por segundo, percentil e ponto de joelho

Sem esse vocabulário, o relatório do teste engana mais do que informa. São quatro números no relatório e duas formas de lê-los.

• Usuário virtual: o visitante simulado pelo programa de teste, que pede páginas em sequência como uma pessoa faria. Na prática, “acesso simultâneo” é quantos usuários virtuais estão em atividade ao mesmo tempo.
• Requisição por segundo (RPS): quantos pedidos de página ou arquivo o servidor responde a cada segundo. É a vazão da máquina, não a contagem de gente.
• Tempo de resposta: quanto demora entre o pedido e a página pronta. É o que o cliente sente.
• Taxa de erro: porcentagem de requisições que voltaram erro ou estouraram o tempo limite em vez de entregar página. Os códigos 502 (o servidor da frente não obteve resposta válida da aplicação), 503 (serviço indisponível, sem capacidade livre) e 504 (a aplicação demorou além do tempo limite) são a assinatura de fila cheia no pico.

A média de tempo de resposta é a armadilha mais comum. Uma média boa esconde a minoria que esperou muito — e essa minoria pode ser justamente quem estava no checkout. Use percentil: no percentil 95 (p95), 95% das requisições foram mais rápidas que aquele valor e 5% foram mais lentas. Olhe p95 e p99, nunca só a média.

O dado que fecha a conta é o ponto de joelho: a carga em que o tempo de resposta para de subir devagar e empina, formando um cotovelo no gráfico. Esse é o teto da máquina. Enquanto há recurso livre o site responde normal; quando o recurso acaba, as requisições passam a esperar umas pelas outras e a piora vira degrau, não rampa.

Regra de leitura: o teto útil é a carga imediatamente antes do joelho, não a carga em que o site caiu. O número em que o site caiu não serve para planejar nada.

Qual ferramenta gratuita usar para simular muitos visitantes ao mesmo tempo

O critério de escolha: quem não é de infraestrutura pega k6 ou Locust, porque o que falta não é força bruta, é cenário. Teste de URL única costuma produzir o resultado que mais engana — um número alto obtido batendo numa página que o cache responde inteira.

Onde o teste roda importa tanto quanto a ferramenta: de fora do servidor testado, de outra máquina e outra rede. Gerador de carga instalado na mesma VPS compete por CPU com a loja e falseia o resultado. Para o primeiro diagnóstico, nenhuma ferramenta paga é necessária.

Como montar um cenário que se pareça com a loja real

O erro mais comum é apontar a ferramenta para a home. A home costuma ser a página mais cacheada do site: o teste mede o cache, entrega um número enorme e não diz nada sobre a loja.

O caminho mínimo que representa uma loja de verdade é este: home → página de categoria (com filtro e paginação) → página de produto → adicionar ao carrinho → ver carrinho. Busca interna entra no cenário se a sua loja vende por busca.

O carrinho é o item que importa. Carrinho, checkout e área do cliente não podem ser servidos de cache compartilhado, então cada visita ali executa aplicação e banco de dados. É onde o teto real mora — e é justamente o trecho que some do teste quando alguém martela só a home.

• Distribuição realista: a maior parte dos usuários virtuais navegando catálogo e uma fração indo ao carrinho, imitando a proporção que o analytics da sua própria loja já mostra.
• Varie produtos e categorias em vez de repetir a mesma URL. Repetindo, o cache cobre tudo depois da primeira requisição e o resultado vira ficção.
• Rampa, não tudo de uma vez: subir a carga aos poucos é o que faz o ponto de joelho aparecer no gráfico. Disparar o máximo de saída só mostra o site no chão, sem dizer onde ele empinou.
• Tempo de pausa entre as páginas: o visitante lê antes de clicar. Sem essa pausa, cada usuário virtual pede páginas muito mais rápido que uma pessoa e o teste subestima quantos visitantes reais a máquina aguentaria.

Cuidados obrigatórios antes de disparar o teste

Teste de carga mal combinado vira incidente real, cobrança real ou bloqueio do provedor. Antes de rodar:

1. Onde testar. O ideal é uma cópia do ambiente — máquina do mesmo tamanho, mesma configuração. Em produção, só em horário de baixa, com alguém acompanhando e ciente de que dá para tirar a loja do ar.
2. Gateway de pagamento. Pare o cenário no carrinho ou use o ambiente de teste (sandbox) do gateway; nunca deixe o teste concluir pedido de verdade.
3. Avise o provedor da VPS antes. Uma mensagem ao suporte com data, hora, duração e IP de origem evita que o teste seja lido como ataque.
4. CDN e cache na frente mascaram o resultado. Se a CDN responde, você mediu a CDN. Para medir o servidor, teste também um caminho que fura o cache — páginas não cacheáveis, ou um cabeçalho de identificação combinado com o provedor de CDN — e compare os dois resultados.
5. Estoque e integrações. Adicionar ao carrinho em massa pode reservar estoque e disparar sincronização com ERP. Confira antes o que o seu fluxo dispara.
6. Higiene de produção. Backup recente, janela curta e registro do que estava rodando na VPS durante o teste (backup, cron, importação), para não medir ruído.
7. Não teste site de terceiro nem servidor que não é seu. Sem autorização, isso é ataque, não diagnóstico.

Como ler o número que saiu e comparar com o pico da sua loja

Anote três coisas do teste: a carga imediatamente antes do joelho, o p95 nessa carga e a taxa de erro nessa carga. Isso é o seu teto medido.

Defina o aceitável antes de olhar o gráfico: acima de que p95 e de que taxa de erro a experiência já é ruim para a sua loja. Quem decide depois decide para caber no resultado.

A expectativa de pico vem do analytics da própria loja — usuários ativos no minuto e na hora de maior movimento em campanhas anteriores —, não de estimativa de fora. O pico costuma ser um múltiplo do dia normal, e esse múltiplo é o da sua loja, medido nas datas que já passaram.

Com os dois números lado a lado, há três desfechos:

• Teto folgado, bem acima do pico esperado: nada a fazer além de repetir o teste depois de mudanças.
• Teto rente ao pico: ajuste e cache costumam resolver, e é o caminho mais barato.
• Teto abaixo do pico: falta capacidade em horas específicas, e aí a conversa muda de assunto — o custo disso está em servidor maior ou reforço só no pico.

Loja nova, sem histórico: use uma data menor do calendário como ensaio e meça o pico real dela antes da data grande. As datas e o que preparar em cada uma estão no calendário de picos do e-commerce brasileiro. E repita o teste depois de cada mudança: um número de teste de carga só vale comparado com o anterior, no mesmo cenário.

Se o teste derruba o site com pouquíssima carga, o problema não é falta de máquina

Sintoma: o joelho aparece com carga baixa, ou 502 e 503 pipocam quase desde o começo da rampa. Isso aponta para gargalo de configuração, não para tamanho de servidor.

Os suspeitos de sempre: cache de página desligado (ou cacheando o que não devia), cache de objeto ausente, número de processos da aplicação configurado abaixo do que a máquina suporta, limite de conexão do banco, consulta sem índice, tarefa agendada rodando junto com a visita.

Comprar máquina nesse estado é caro e pouco eficaz: o desperdício por requisição continua, o teto sobe menos do que o custo e você paga o mês inteiro para adiar o mesmo problema. A ordem correta é arrumar o que é barato, medir de novo e só então discutir capacidade. O roteiro de diagnóstico está em como achar o gargalo na sua VPS.

Se for esse o seu caso, o assunto termina nesta seção e não precisa de produto nenhum — nem do nosso.

Quando o teto medido é real e fica abaixo do pico: onde o SwarmBurst entra

Existe o caso em que a loja já está otimizada, o teste foi repetido, o teto medido é confiável — e ainda assim sobram poucas horas no mês em que o pico esperado passa do teto. Só esse caso.

O SwarmBurst é um agente de cloud bursting instalado no cluster do próprio cliente. A aplicação segue na VPS fixa na operação normal e, quando o uso passa do ponto que você definiu, sobem servidores extras por hora na nuvem da Amazon, que entram no cluster e passam a atender junto. Caído o movimento, esses nós são drenados, removidos, e a cobrança deles termina ali. Você define um teto de gasto, para que o reforço por hora não vire susto na fatura.

A VPS continua dona do estado — banco de dados, arquivos enviados, painel. Não é migração de hospedagem: sua loja continua onde está.

Pré-requisito honesto: só funciona se a loja rodar em contêineres, dentro de um cluster. Loja em VPS com nginx, PHP e MySQL instalados direto no sistema tem um passo anterior de containerização, que é trabalho de verdade e entra no diagnóstico antes de qualquer proposta.

O teste de carga é o que qualifica essa conversa. Sem número medido, qualquer proposta de capacidade é chute — inclusive a nossa. Com número medido, a decisão vira aritmética de horas, e esse cálculo está em servidor maior ou reforço só no pico.

Perguntas frequentes

Posso rodar teste de carga na loja em produção sem quebrar nada?

O ideal é testar em uma cópia do ambiente: máquina do mesmo tamanho e mesma configuração. Em produção, rode apenas em horário de baixa, com alguém acompanhando e ciente de que o teste pode tirar a loja do ar.

Antes de disparar, tenha backup recente, use uma janela curta e anote o que estava rodando na VPS durante o teste (backup, cron, importação), para não medir ruído.

Preciso avisar o provedor da VPS antes de fazer teste de carga para não parecer ataque?

Sim. Uma mensagem ao suporte com data, hora, duração e IP de origem evita que o teste seja lido como ataque.

E vale a regra que não tem exceção: não teste site de terceiro nem servidor que não é seu. Sem autorização, isso é ataque, não diagnóstico.

O teste de carga pode disparar pedido de verdade no gateway de pagamento?

Pode, se o cenário for até o fim do checkout. Pare o cenário no carrinho ou use o ambiente de teste (sandbox) do gateway; nunca deixe o teste concluir pedido de verdade.

Vale checar também o que o seu fluxo dispara antes do pagamento: adicionar ao carrinho em massa pode reservar estoque e acionar sincronização com o ERP.

O cache e a CDN na frente do site mascaram o resultado do teste?

Sim. Se a CDN responde, você mediu a CDN, não o servidor. Para medir a VPS, teste também um caminho que fura o cache — páginas não cacheáveis, ou um cabeçalho de identificação combinado com o provedor de CDN — e compare os dois resultados.

No cenário, varie produtos e categorias em vez de repetir a mesma URL: repetindo, o cache cobre tudo depois da primeira requisição e o número vira ficção. Martelar só a home tem o mesmo efeito, porque costuma ser a página mais cacheada do site.

Quantos usuários virtuais eu devo usar no teste?

Não existe número fixo para começar: o que define é a rampa. Suba a carga aos poucos até o tempo de resposta parar de crescer devagar e empinar — esse cotovelo no gráfico é o ponto de joelho. Disparar o máximo de saída só mostra o site no chão, sem dizer onde ele empinou.

O teto útil é a carga imediatamente antes do joelho, não a carga em que o site caiu. Anote essa carga, o p95 e a taxa de erro nela, e compare com o pico esperado da sua loja, tirado do analytics — usuários ativos no minuto e na hora de maior movimento em campanhas anteriores.