Quantos usuários simultâneos um VPS aguenta: faça o cálculo

Dos usuários às requisições

“Usuários simultâneos” designa três grandezas diferentes, dependendo de quem fala:

• As contas cadastradas: não custam nada ao servidor enquanto não se conectam.
• Os usuários ativos ao mesmo tempo: pessoas que navegam, leem, preenchem um formulário. Cada uma envia uma requisição de vez em quando, tipicamente a cada 10 a 30 segundos, mais algumas chamadas de API por tela em uma aplicação moderna.
• As requisições em processamento: as que o servidor está calculando em um dado instante. É a única grandeza que consome processador e memória.

Passa-se de uma à outra pela lei de Little: o número de requisições em andamento é igual à vazão, em requisições por segundo, multiplicada pela duração média de uma requisição.

Exemplo. 600 usuários ativos ao mesmo tempo, cada um disparando uma requisição a cada 20 segundos, geram 30 requisições por segundo. Se cada requisição dura 100 ms, o servidor tem apenas 3 requisições em andamento, em média. O desafio está em outro lugar: nos picos e nas requisições lentas.

O que um vCPU aguenta

Uma requisição ocupa o processador durante o cálculo dela: executar o código, consultar o banco, montar a resposta. Um vCPU processa, portanto, no máximo 1.000 ÷ t requisições por segundo, em que t é o tempo de cálculo de uma requisição em milissegundos. O tempo gasto esperando (uma API externa, um disco) não ocupa o processador, mas ocupa um worker.

Com essas ordens de grandeza, 30 requisições de API por segundo com 10 ms de cálculo ocupam 30% de um único vCPU. As mesmas 30 requisições por segundo em páginas WordPress sem cache pedem 3 a 9 vCPU. O cache de páginas serve justamente para levar uma página da quarta linha da tabela para a segunda.

O que a memória aguenta

Cada requisição em andamento é atendida por um worker, e os workers ocupam memória, trabalhando ou não. Muitas vezes é a memória, mais do que o processador, que define o número de requisições processadas em paralelo:

• PHP-FPM: um processo por requisição em andamento, 40 a 80 MB cada. pm.max_children define o teto: 20 processos são 800 MB a 1,6 GB.
• Python (Gunicorn, Uvicorn): a documentação do Gunicorn sugere partir de (2 × número de núcleos) + 1 workers, de 80 a 200 MB cada. Um worker assíncrono mantém muitas requisições em espera com a memória de um único processo.
• Node.js: um único processo mantém milhares de conexões em espera, mas usa apenas um núcleo; o modo cluster, ou o PM2, inicia um processo por vCPU.
• O banco de dados: o PostgreSQL abre um processo por conexão e aceita 100 por padrão. Acima de algumas dezenas de conexões ativas, um pool de conexões como o PgBouncer é melhor do que aumentar max_connections.

As conexões persistentes (websockets, notificações em tempo real) contam à parte: abertas o tempo todo, elas ocupam pouco processador e algumas dezenas de kilobytes de memória cada uma. Um servidor Node.js mantém milhares delas em algumas centenas de MB.

Os verdadeiros gargalos

Em uma aplicação real, o servidor raramente satura onde se espera. As causas mais frequentes, na ordem em que vale procurar:

1. Uma consulta SQL lenta: um índice ausente transforma uma consulta de 2 ms em uma consulta de 2 segundos, que prende um worker e uma conexão. O pg_stat_statements no PostgreSQL, ou o log de consultas lentas do MySQL, aponta qual é.
2. As consultas em cascata (o problema N+1): uma página que dispara uma consulta por linha exibida dispara centenas delas.
3. Uma chamada externa síncrona: uma API de pagamento ou de IA que responde em 3 segundos bloqueia um worker síncrono durante 3 segundos.
4. Processamentos pesados dentro da requisição: envio de e-mails, redimensionamento de imagens, geração de PDF, a transferir para uma fila de tarefas.
5. A falta de cache: as páginas idênticas para todos os visitantes são servidas a partir de um cache, e os arquivos estáticos, pelo servidor web.

Verificar: o teste de carga

As ordens de grandeza dão um primeiro tamanho; um teste de carga dá o tamanho real. O princípio: simular usuários cada vez mais numerosos em uma cópia da aplicação e registrar o momento em que o tempo de resposta dispara.

wrk -t2 -c50 -d30s --latency https://homologacao.seu-site.com/

Para um percurso completo (login, navegação, busca), o k6 descreve um cenário em JavaScript e aumenta a carga em etapas:

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '2m', target: 300 },
    { duration: '5m', target: 300 },
    { duration: '2m', target: 0 },
  ],
  thresholds: { http_req_duration: ['p(95)<500'] },
};

export default function () {
  http.get('https://homologacao.seu-site.com/');
  sleep(15);
}

• Teste uma cópia, não a produção, e avise seu provedor se o teste visar um servidor que ele opera.
• Rode o teste a partir de outra máquina, e não do servidor testado; caso contrário, a ferramenta consome os recursos dele.
• Observe o percentil 95 do tempo de resposta, não a média: é o que vivem seus usuários menos bem atendidos.
• Acompanhe o servidor durante o teste: htop para o processador, free -h para a memória, os logs para os erros.

Quando a carga cresce

A ordem que custa menos e rende mais:

1. Colocar em cache o que puder ser colocado (páginas, fragmentos, resultados de consultas) e corrigir as consultas lentas.
2. Ajustar o número de workers à memória e ao processador disponíveis.
3. Passar para um tamanho superior: mais vCPU e memória, sem mudar nada na aplicação.
4. Colocar o banco de dados em um servidor próprio.
5. Distribuir a aplicação entre vários servidores atrás de um balanceador de carga.

As três primeiras etapas cobrem a grande maioria das aplicações de gestão, dos sites e das APIs: várias centenas de usuários ativos ao mesmo tempo cabem em um único servidor bem ajustado.