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

Revisado em 12/11/2026: incluído um exemplo de catálogo em k6 e esclarecidos os limites da medição.

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. Usuários virtuais são uma escolha do modelo do teste; não equivalem automaticamente aos usuários ativos mostrados no analytics.
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 HTTP: quanto demora a requisição no cenário medido. Não inclui, por si só, executar JavaScript e renderizar a página no navegador.
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 (resposta inválida do upstream), 503 (serviço indisponível) e 504 (tempo limite no upstream) ajudam a localizar a falha, mas não comprovam fila cheia ou falta de capacidade.

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 é um sinal de saturação do sistema naquele cenário; correlacione com métricas para localizar o recurso limitante. 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

Ferramenta	Como o teste é escrito	Para que serve
Apache Bench (ab)	Linha de comando, uma URL só	Martela um endereço e responde "quanto essa página entrega". Instala em minutos. Bom para primeiro sinal, insuficiente para representar uma loja.
wrk	Linha de comando, com script opcional em Lua	Gera mais carga que o ab por usar várias threads. Sem script, continua sendo teste de URL única.
k6	Cenário em JavaScript	Rampa de usuários virtuais e relatório já em percentil. É a escolha padrão quando se quer um caminho de navegação e não uma URL.
Locust	Cenário em Python	Painel no navegador para subir e descer a carga durante o teste. Bom para quem já tem alguém que escreve Python por perto.

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.

Script k6 para baixar: primeiro valide o catálogo com pouca carga

Baixar o exemplo de teste de catálogo em k6.

O arquivo faz apenas requisições GET aos caminhos que você informar. Ele não adiciona produtos ao carrinho, não cria pedidos e não chama pagamento. É um teste inicial de funcionamento (smoke test), não uma medição completa da capacidade da loja. Mesmo um GET pode disparar tarefas em aplicações mal configuradas: use somente rotas de leitura que você revisou, em ambiente próprio autorizado.

Instale o k6 pelo guia oficial da Grafana, salve o arquivo e configure o teste. Exemplo para um ambiente de homologação que você controla, acessível localmente na porta 8080:

k6 run \
  -e BASE_URL=http://127.0.0.1:8080 \
  -e ALLOWED_ORIGIN=http://127.0.0.1:8080 \
  -e PATHS=/,/categoria/camisetas/,/produto/camiseta/ \
  -e EXPECT_TEXT='Minha loja de teste' \
  teste-capacidade-k6.js

Troque os caminhos pelos que existem na sua cópia da loja. BASE_URL e ALLOWED_ORIGIN precisam ser a mesma origem exata, com protocolo e porta; essa confirmação reduz erros de digitação, mas não verifica a propriedade do site. Não coloque domínio de terceiro. PATHS aceita caminhos sem query string; rotas que modificam estado não devem entrar. Se o catálogo exige parâmetros ou usa outro formato, o responsável técnico deve adaptar e revisar o script antes de executar.

EXPECT_TEXT é opcional: escolha uma expressão presente nas páginas esperadas para distinguir uma resposta útil de uma tela de erro com status 200. Se cada página tem conteúdo diferente, personalize os checks por rota. O teste não segue redirecionamentos: uma resposta 301 ou 302 pede que você confira a origem e o caminho final antes de continuar.

Carga e critérios usados no exemplo

Os valores abaixo são configurações didáticas, não benchmarks nem limites recomendados para qualquer loja:

Configuração	Padrão do arquivo	Como interpretar
`VUS`	1 usuário virtual	Começo pequeno para validar o roteiro; cada usuário faz um GET por vez e pausa dois segundos.
`SECONDS`	20 segundos	Janela curta; insuficiente para estimar capacidade sustentada.
`P95_MS`	1500 milissegundos	Critério ilustrativo de tempo HTTP; substitua pelo objetivo definido para sua aplicação. Não mede renderização no navegador.
Checks	HTTP 200, HTML e texto opcional	Confirmam resposta esperada; não comprovam compra funcionando.
Erros HTTP	Menos de 1%	Critério ilustrativo. Com amostra pequena, um erro já pode reprovar.

O arquivo permite até dez usuários virtuais e até 120 segundos por execução. São limites de escopo deste exemplo, não atestado de segurança: até carga pequena pode afetar uma aplicação frágil. Os critérios são avaliados durante a execução, com início da possibilidade de interrupção após dez segundos; não são proteção instantânea. Interrompa com Ctrl+C se a aplicação degradar ou o monitoramento indicar problema.

Como ler o resultado sem confundir catálogo com capacidade

Check falhou: primeiro confira rota, redirecionamento, conteúdo retornado e autenticação. Não aumente usuários para investigar erro funcional.
http_req_failed reprovou: confira respostas e logs; bloqueio de CDN ou rate limiting também pode causar falha.
http_req_duration reprovou: o p95 ultrapassou o critério escolhido. Compare com CPU, memória, fila da aplicação e banco no mesmo intervalo.
Tudo passou: só significa que esse roteiro de catálogo passou com essa carga, janela e critérios. O script não carrega imagens, executa JavaScript nem reproduz checkout.

Depois que o roteiro estiver correto, faça uma segunda execução com -e VUS=2, acompanhando as métricas e conservando os mesmos caminhos. Não extrapole o resultado para visitantes reais: usuários ativos no analytics, usuários virtuais e requisições por segundo são medidas diferentes.

Para descobrir o teto, o próximo passo é um cenário revisado que represente os fluxos reais, com rampa, duração adequada e limites de interrupção acordados. O relatório agregado deste exemplo não localiza sozinho o ponto de joelho. A seção seguinte explica o que falta modelar.

O uso de __ENV, critérios de aprovação e interrupção segue a documentação de variáveis de ambiente, thresholds e parâmetros HTTP do k6.

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:

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.
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.
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.
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.
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.
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.
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

No teste completo com rampa, anote a carga imediatamente antes do joelho, o p95 e a taxa de erro naquele intervalo. Isso dá uma capacidade observada para aquele cenário, não uma garantia universal da VPS.

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 falha com pouca carga, investigue antes de comprar máquina

Sintoma: o joelho aparece com carga baixa, ou 502 e 503 pipocam quase desde o começo da rampa. Isso pede investigação: configuração, código, dependências externas e capacidade insuficiente são hipóteses. O teste sozinho não distingue essas causas.

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 de execução dessas instâncias deixa de acumular; volumes e outros recursos precisam ser verificados separadamente. 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. Use o analytics para orientar a distribuição e a chegada de visitas, mas modele a relação com usuários virtuais: usuários ativos em um intervalo não são a mesma medida de concorrência ou RPS do teste.