Quantos utilizadores simultâneos aguenta um VPS: fazer as contas

Dos utilizadores aos pedidos

«Utilizadores simultâneos» designa três grandezas diferentes, conforme quem fala:

• As contas registadas: não custam nada ao servidor enquanto não iniciam sessão.
• Os utilizadores ativos ao mesmo tempo: pessoas que navegam, leem, preenchem um formulário. Cada uma envia um pedido de vez em quando, tipicamente a cada 10 a 30 segundos, mais algumas chamadas de API por ecrã numa aplicação moderna.
• Os pedidos em processamento: os que o servidor calcula num dado instante. É a única grandeza que consome processador e memória.

Passa-se de uma para a outra pela lei de Little: o número de pedidos em curso é igual ao débito, em pedidos por segundo, multiplicado pela duração média de um pedido.

Exemplo. 600 utilizadores ativos ao mesmo tempo, cada um a desencadear um pedido a cada 20 segundos, fazem 30 pedidos por segundo. Se cada pedido durar 100 ms, o servidor tem apenas 3 pedidos em curso em média. O desafio está noutro lado: nos picos e nos pedidos lentos.

O que aguenta um vCPU

Um pedido ocupa o processador durante o seu cálculo: executar o código, consultar a base de dados, construir a resposta. Um vCPU trata portanto no máximo 1 000 ÷ t pedidos por segundo, em que t é o tempo de cálculo de um pedido em milissegundos. O tempo passado à espera (uma API externa, um disco) não ocupa o processador, mas ocupa um worker.

Com estas ordens de grandeza, 30 pedidos de API por segundo com 10 ms de cálculo ocupam 30 % de um único vCPU. Os mesmos 30 pedidos por segundo em páginas WordPress sem cache pedem 3 a 9 vCPU. A cache de páginas serve precisamente para fazer passar uma página da quarta linha da tabela para a segunda.

O que aguenta a memória

Cada pedido em curso é tratado por um worker, e os workers ocupam memória, quer estejam a trabalhar quer não. É muitas vezes a memória, mais do que o processador, que define o número de pedidos tratados em paralelo:

• PHP-FPM: um processo por pedido em curso, 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 propõe partir de (2 × número de núcleos) + 1 workers, de 80 a 200 MB cada. Um worker assíncrono mantém muitos pedidos em espera com um único processo.
• Node.js: um único processo mantém milhares de ligações em espera, mas usa apenas um núcleo; o modo cluster, ou o PM2, lança um processo por vCPU.
• A base de dados: o PostgreSQL abre um processo por ligação e aceita 100 por predefinição. Acima de algumas dezenas de ligações ativas, um agregador de ligações como o PgBouncer é preferível a um aumento de max_connections.

As ligações persistentes (websockets, notificações em tempo real) contam-se à parte: abertas em permanência, ocupam pouco processador e algumas dezenas de kilobytes de memória cada. Um servidor Node.js aguenta milhares delas em algumas centenas de MB.

Os verdadeiros estrangulamentos

Numa aplicação real, o servidor raramente satura onde se espera. As causas mais frequentes, pela ordem em que as procurar:

1. Uma consulta SQL lenta: um índice em falta transforma uma consulta de 2 ms numa consulta de 2 segundos, que retém um worker e uma ligação. O pg_stat_statements no PostgreSQL, ou o registo de consultas lentas do MySQL, identifica-a.
2. As consultas em cascata (o problema N+1): uma página que lança uma consulta por cada linha apresentada lança 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 do pedido: envio de e-mails, redimensionamento de imagens, geração de PDF, a passar para uma fila de tarefas.
5. A ausência de cache: as páginas iguais para todos os visitantes servem-se a partir de uma cache, os ficheiros estáticos a partir do servidor web.

Verificar: o teste de carga

As ordens de grandeza dão um primeiro tamanho; um teste de carga dá o verdadeiro. O princípio: simular utilizadores cada vez mais numerosos numa cópia da aplicação, e registar o momento em que o tempo de resposta dispara.

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

Para um percurso completo (início de sessão, navegação, pesquisa), o k6 descreve um cenário em JavaScript e faz subir a carga por patamares:

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://preprod.o-seu-site.com/');
  sleep(15);
}

• Teste uma cópia, não a produção, e avise o seu fornecedor de alojamento se o teste visar um servidor que ele explora.
• Lance o teste a partir de outra máquina que não o servidor testado; caso contrário, a ferramenta consome-lhe os próprios recursos.
• Olhe para o 95.º percentil do tempo de resposta, não para a média: é o que vivem os seus utilizadores mais mal servidos.
• Observe o servidor durante o teste: htop para o processador, free -h para a memória, os registos para os erros.

Quando a carga aumenta

A ordem que custa menos e rende mais:

1. Pôr em cache o que pode sê-lo (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 a um tamanho superior: mais vCPU e mais memória, sem mudar nada na aplicação.
4. Colocar a base de dados no seu próprio servidor.
5. Distribuir a aplicação por 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 API: várias centenas de utilizadores ativos ao mesmo tempo cabem num único servidor bem ajustado.