Mil alunos simulados fizeram uma prova de verdade no Moodle, em degraus de 100, 300, 600 e 1000, enquanto o painel media cada parte do servidor. Este é o passo a passo.
O k6 (ferramenta de teste de carga) rodou dentro do servidor, num container limitado a 1 CPU (e 3 GiB no degrau de 1000), falando com o nginx pela rede interna. Assim o teste mede o servidor, não a internet.
Entra, abre a prova, responde, o navegador salva sozinho e no fim envia. Os arquivos do tema (CSS/JS) são baixados na primeira visita, como num navegador de verdade. Veja ao lado.
Rajada: todos entram em uns 2 min. Prova: 5 min de salvamentos. Envio em massa: todos enviam em ~1 min. Depois, pausa.
Removidos 1200 usuários, o curso, 2007 tentativas e 47.581 linhas de log. Acesso reaberto e manutenção religada.
p95: 95 de cada 100 alunos esperaram menos que esse tempo.
Ensaio com 20 alunos a partir do Brasil, mesma prova:
A rede limitava, não o servidor. Por isso os degraus rodaram de dentro.
1000: segundo disparo. O primeiro parou em ~1 min porque o gerador k6 ficou sem memória; o servidor não teve erro nem efeito. O ensaio de 20 alunos pela VPN não entra na tabela.
Carga acima de 8 significa processos esperando CPU. Em 1000 a fila chegou a 101 para 8 vCPU.
Com 1000 alunos entrando juntos, os 8 vCPU lotaram (carga 101). A memória sobrou (app 1,6 de 18 GiB, swap 0), então o pedido é só de processador. O número exato se confirma com um novo teste.
Cada aluno baixa CSS, JS, fontes e imagens do tema na primeira visita, e hoje cada arquivo passa pelo Apache e pelo PHP. Um CDN (ex.: Cloudflare) entrega esses arquivos, tira esse tráfego do servidor e fica mais perto dos alunos em Angola. Exige alterar o DNS do domínio.
O gerador usou 1 dos 8 vCPUs do próprio host. Numa prova real esse núcleo fica para o Moodle.