Alunos Simultâneos Moodle: Quanto Seu Servidor Aguenta

Quantos alunos simultâneos Moodle o seu servidor aguenta é a pergunta que toda coordenação de EAD faz uma semana antes da prova, e quase nunca com o número certo na mão. A resposta não está na ficha técnica do servidor nem no plano da hospedagem. Ela sai de um teste de carga, de três ou quatro métricas que você consegue ler hoje e de uma conta simples que vou mostrar passo a passo.

TL;DR

• "Simultâneo" não é "logado". O que derruba o Moodle é requisição em processamento, não a lista de usuários online.
• A própria documentação do Moodle estima que, no pior caso, um site atende só 10 a 20 usuários concorrentes por GB de RAM. Use como piso, não como meta.
• O gargalo real quase sempre é um destes quatro: workers do PHP-FPM, sessões, cache (MUC) ou banco de dados.
• O pior cenário documentado é uma turma grande clicando em "Iniciar tentativa" de um questionário com tempo, todos no mesmo minuto.
• Para estimar alunos simultâneos Moodle com segurança, junte uma conta de memória com um teste de carga que reproduza a sua pior prova.
• Teste de carga se faz em homologação, com o gerador de plano JMeter do próprio Moodle. Nunca em produção.

O que "alunos simultâneos" quer dizer de verdade

Antes de qualquer conta, alinhe o vocabulário com a sua equipe. Na prática, uma instituição usa três números diferentes como se fossem o mesmo:

• Alunos matriculados: quantas contas existem. Uma faculdade com 12.000 matriculados pode ter 300 pessoas no ambiente numa terça à tarde.
• Usuários online: o bloco "Usuários online" do Moodle mostra quem teve atividade nos últimos minutos (por padrão, 5). É uma janela de tempo, não carga real.
• Usuários concorrentes: a documentação de desempenho do Moodle define como "aqueles usuários para quem o servidor está ativamente fazendo algo". É esse o número que importa.

A diferença é grande. Um aluno lendo um PDF por 15 minutos aparece como online, mas não ocupa o servidor. Já 400 alunos que clicam em "Enviar" na mesma janela de 30 segundos ocupam tudo.

Por que a prova sincronizada é o pior caso

O próprio Moodle diz isso com todas as letras: o pior cenário possível é uma turma grande iniciando um questionário com tempo exatamente ao mesmo tempo. Cada "Iniciar tentativa" cria registros no banco, sorteia questões, grava sessão e carrega a primeira página. Multiplique por 800 alunos no mesmo minuto e você tem um pico que não aparece em nenhuma média mensal.

Quando eu dimensiono capacidade de alunos simultâneos Moodle para uma instituição, a primeira pergunta não é "quantos alunos vocês têm". É "qual é a maior prova sincronizada do semestre, e quantos alunos fazem ao mesmo tempo".

A regra de bolso oficial e por que ela engana

A Performance FAQ do Moodle traz a estimativa mais citada nos fóruns: "muito grosseiramente, no pior caso, seu site Moodle pode atender apenas 10 a 20 usuários concorrentes por GB de memória". O mesmo texto lembra que o Moodle pode usar facilmente mais de 50 MB de RAM por processo, às vezes bem mais.

Pela regra, um servidor de 16 GB atenderia entre 160 e 320 usuários concorrentes. Já vi servidor de 16 GB bem ajustado segurar muito mais do que isso em navegação comum, e já vi servidor de 32 GB travar com 300 alunos numa prova. A regra serve para uma coisa só: detectar quando o servidor está claramente subdimensionado. Para planejar alunos simultâneos Moodle de verdade, ela é insuficiente.

A página de instalação do Moodle é ainda mais honesta. Ela diz que um post de fórum do tipo "que hardware preciso para 50.000 usuários?" dificilmente terá uma resposta útil. O número depende de configuração, sistema operacional e, principalmente, do que os alunos estão fazendo.

O que muda a conta

Fator	Efeito na capacidade	Onde olhar
Tipo de atividade	Questionário e envio de tarefa pesam muito mais que leitura de página	Logs por horário e por módulo
Sessões em arquivo vs Redis	Sessão em disco trava requisições do mesmo aluno em fila	config.php e Administração do site → Plugins → Caching
OPcache	Sem ele, cada requisição recompila o PHP	Relatório de ambiente do Moodle
Banco sem tuning	Consulta lenta segura o worker do PHP-FPM ocupado	Slow query log do MariaDB
Plugins de terceiros	Um bloco mal escrito na página do curso multiplica queries	Informações de desempenho no rodapé
Cron atrasado	Tarefas acumuladas disputam CPU no horário de aula	Tarefas agendadas

A conta que eu faço antes de qualquer teste

Teste de carga confirma uma hipótese. Antes dele, você precisa da hipótese. Ela sai de três medidas que qualquer servidor Linux fornece.

1. Quanto cada processo PHP consome

Com o ambiente em uso real, meça a memória média dos processos php-fpm (o ps ou o painel do seu monitoramento mostram). Em Moodle, valores entre 60 e 120 MB por processo são comuns; plugins pesados e relatórios empurram para cima.

2. Quanta RAM sobra para o PHP

Do total do servidor, desconte sistema operacional, banco de dados (se estiver na mesma máquina), Redis e uma margem de segurança. O que sobra é o orçamento do PHP-FPM.

3. Quanto tempo dura uma requisição

O relatório de desempenho e as informações de desempenho do Moodle mostram o tempo de geração das páginas. Uma página de curso típica bem ajustada fica na casa de centenas de milissegundos.

Exemplo hipotético, com números redondos

Um servidor de 16 GB com banco na mesma máquina: reserve 6 GB para MariaDB, Redis e sistema. Sobram 10 GB para o PHP. Com processos de 80 MB, isso dá cerca de 125 workers (pm.max_children). Se cada requisição dura 250 ms, cada worker atende 4 por segundo, e o servidor processa algo perto de 500 requisições por segundo no teto teórico.

Agora traduza em alunos. Um aluno navegando gera uma página a cada 20 ou 30 segundos, e cada página dispara algumas chamadas AJAX. Numa prova, o comportamento muda: todos clicam ao mesmo tempo. Por isso o mesmo servidor que aguenta milhares de alunos navegando pode sofrer com algumas centenas iniciando um questionário no mesmo minuto.

Essa estimativa de alunos simultâneos Moodle é ponto de partida. Quem fecha o número é o teste de carga.

PHP-FPM: o primeiro limite que você bate

O manual do PHP define pm.max_children como o número máximo de processos filhos e diz que ele "define o limite de requisições simultâneas que serão atendidas". Na conta de alunos simultâneos Moodle, este é o número que manda. Quando todos os workers estão ocupados, a requisição seguinte entra numa fila. O aluno vê a página "carregando" e, se a fila cresce, recebe um 502 ou 504.

Os dois erros mais comuns que encontro:

• pm.max_children baixo demais: o servidor tem RAM sobrando e mesmo assim enfileira. Típico de hospedagem compartilhada ou configuração padrão de distribuição.
• pm.max_children alto demais: alguém aumentou para "aguentar a prova", a RAM acabou, o sistema entrou em swap e o servidor inteiro ficou mais lento do que antes. Mais workers do que memória é pior do que fila.

O que monitorar no PHP-FPM

Ative a página de status (pm.status_path) e acompanhe três campos durante o horário de pico: processos ativos, listen queue (requisições esperando worker) e max children reached (quantas vezes o limite foi atingido). Se max children reached sobe toda segunda de manhã, você já sabe onde está o teto.

Ligue também o request_slowlog_timeout. Ele grava um backtrace de toda requisição que passar do tempo definido. Em quase todo diagnóstico, o slowlog aponta um plugin ou uma consulta específica, não "falta de servidor". Se o seu ambiente já está lento fora da prova, comece pelo roteiro de diagnóstico de Moodle lento antes de pensar em capacidade.

Sessões e cache: onde o Moodle trava sem usar CPU

Esse é o gargalo que mais engana, porque o servidor parece ocioso e mesmo assim os alunos esperam.

Sessões

A documentação de sessões do Moodle explica que o driver em arquivo é o padrão das instalações novas, e que o driver em banco tem desempenho "relativamente baixo" e não é recomendado para sites grandes. Para escala, o Moodle aponta drivers em memória (Memcached ou Redis) e sessões somente leitura em páginas que não precisam de trava de escrita.

O problema da sessão é o lock: enquanto uma requisição do aluno segura a sessão, as outras do mesmo aluno esperam. Num questionário com salvamento automático e várias chamadas AJAX, isso vira fila invisível, e derruba a capacidade de alunos simultâneos Moodle mesmo com CPU sobrando.

Cache (MUC)

O Moodle Universal Cache guarda dados de aplicação e de sessão. Por padrão, boa parte dele vai para o disco (moodledata). A página de recomendações de desempenho cita um relato direto: a maior melhoria que um site fez foi instalar o Redis. Em servidor com disco lento ou moodledata em rede, a troca é a diferença entre segurar e não segurar o pico.

Configurar cache e sessão em memória é das primeiras coisas que mexo quando um cliente pergunta quantos alunos simultâneos Moodle ele consegue atender, porque é barato e o ganho é grande.

Banco de dados: o gargalo que aparece por último e custa mais

Quando PHP-FPM e cache estão bem resolvidos, o limite migra para o banco. É o mais caro de resolver, então vale saber reconhecê-lo.

A recomendação número um da documentação do Moodle para MySQL e MariaDB é entender e ajustar o InnoDB buffer pool. Em servidor de banco dedicado, ele pode ocupar até 80% da memória. Se o banco divide máquina com o PHP, essa conta precisa ser feita junto com o orçamento de workers, senão um come a memória do outro.

Sobre conexões, a mesma página diz que normalmente não é necessário passar de 200 max_connections, mesmo em servidores muito carregados. Se você precisa de mais, provavelmente o problema é consulta lenta segurando conexão aberta, não falta de conexão.

Réplica de leitura

Desde o Moodle 3.9 é possível apontar consultas de leitura para réplicas. A documentação estima que isso pode tirar de 80% a 90% da carga do banco primário. Faz sentido em instalações grandes, com relatórios pesados ou muitos acessos simultâneos. Para uma escola com 2.000 alunos, é complexidade sem retorno.

Os requisitos de servidor para Moodle 5.x cobrem versões de PHP e banco suportadas. Aqui o ponto é outro: o banco certo, mal ajustado, ainda vira o teto do seu pico de alunos simultâneos Moodle em dia de prova.

Como fazer o teste de carga de alunos simultâneos Moodle

O Moodle tem ferramenta oficial para isso, e pouca gente usa. São duas peças do tool_generator, ambas para uso exclusivo de desenvolvimento.

Passo 1: monte um ambiente de homologação idêntico

Mesmo hardware (ou proporcional), mesma versão do Moodle, mesmos plugins, mesmo tema. Teste de alunos simultâneos Moodle em ambiente diferente mede outra coisa. A documentação do JMeter no Moodle é explícita: não rode esses scripts nem o JMeter contra produção, porque eles geram muito dado artificial e levam o servidor ao limite e além.

Passo 2: gere um curso de teste

O gerador de curso de teste cria cursos em tamanhos fixos. O tamanho M tem 1.000 usuários e 100 tarefas; o L, 10.000 usuários; o XL, 50.000. O comando é php admin/tool/generator/cli/maketestcourse.php (no Moodle 5.1 em diante, o código fica dentro de public/).

Passo 3: gere o plano JMeter

O gerador de plano de teste cria o arquivo .jmx e o CSV de usuários. No código atual do Moodle, os tamanhos são estes:

Tamanho	Usuários virtuais	Repetições	Rampa (segundos)
XS	1	5	1
S	30	5	6
M	100	5	40
L	1.000	6	100
XL	5.000	6	500
XXL	10.000	7	800

Antes de gerar, defina $CFG->tool_generator_users_password no config.php e ative o modo de depuração de desenvolvedor no ambiente de teste. Rode o plano no Apache JMeter, hoje na versão 5.6.3.

Passo 4: simule a sua prova, não a média

O plano oficial simula navegação no curso gerado. Para responder quantos alunos simultâneos Moodle aguenta na prova, grave também um cenário próprio no JMeter: login, abrir o questionário, iniciar tentativa, responder, finalizar. E reduza a rampa: se a prova abre às 19h e todos entram até 19h02, a rampa é de 120 segundos, não de 800.

Passo 5: leia o resultado certo

Acompanhe no teste: tempo de resposta no percentil 95, taxa de erro, listen queue do PHP-FPM, uso de CPU, RAM e swap, e consultas lentas do banco. O número que você procura é o ponto em que o p95 dispara ou a taxa de erro sai de zero. Esse é o seu teto de alunos simultâneos Moodle naquele cenário. Planeje operar com folga abaixo dele.

Quando NÃO fazer teste de carga, e outras armadilhas

Teste de carga é ferramenta, não ritual. Há momentos em que ele atrapalha.

• Não teste em produção. Nem "rapidinho de madrugada". O gerador cria usuários e cursos falsos que poluem relatórios, e o pico pode derrubar o cron e os backups da noite.
• Não teste antes de ajustar o básico. Se OPcache está desligado ou a sessão está em banco, o teste só confirma o óbvio. Corrija primeiro, teste depois.
• Não teste com cache frio e conclua pelo pior número. Rode uma passada de aquecimento.
• Não confunda o gerador de carga com o servidor. Se o JMeter roda numa máquina fraca, ele vira o gargalo. Use máquina separada.
• Não teste na semana do upgrade. O Moodle 5.3, nova versão LTS, foi lançado em 5 de outubro de 2026 segundo o calendário oficial de releases. Atualizar e medir capacidade ao mesmo tempo mistura duas variáveis. Atualize em homologação, estabilize, depois teste.

Custos que pegam a coordenação de surpresa

O custo do teste em si é baixo: horas de um técnico e um ambiente de homologação por alguns dias. O custo caro é o que vem depois. Escalar a capacidade de alunos simultâneos Moodle por instinto (dobrar o servidor "para garantir") costuma dobrar a fatura mensal sem resolver um lock de sessão. E escalar sem migração planejada pode exigir trocar de servidor com o semestre em andamento, que é exatamente o que um bom roteiro de migração de Moodle sem perder dados tenta evitar.

Sinais de que o servidor já está no limite

Você não precisa esperar a prova cair para saber. Estes sinais aparecem antes:

1. Tempo de resposta sobe toda segunda de manhã ou no horário noturno de aula, e volta ao normal depois.
2. Erros 502 e 504 aparecem em rajadas curtas nos logs do servidor web.
3. max children reached do PHP-FPM cresce semana a semana.
4. O swap começa a ser usado no horário de pico.
5. Alunos relatam que "a prova travou ao enviar", mas a equipe não consegue reproduzir fora do horário.

Se dois ou mais desses aparecem, sua capacidade de alunos simultâneos Moodle já está no teto, mesmo que ninguém tenha reclamado formalmente.

Como a Agathas Web resolve isso

Na Agathas Web, sustento Moodle há mais de 15 anos e capacidade de pico de alunos simultâneos Moodle é a conversa que mais tenho com coordenadores de EAD. O que a hospedagem Moodle gerenciada da Agathas entrega para esse problema, na prática:

• Stack montada para o Moodle: PHP-FPM com pool dedicado por instância, OPcache ajustado, sessões e cache (MUC) em Redis, MariaDB com otimização semanal de índices e cron isolado em worker dedicado.
• Réplica somente leitura para relatórios pesados, para que a consulta da secretaria não dispute banco com a prova.
• Monitoramento 24/7 com Grafana, Prometheus, Sentry e UptimeRobot externo, com alertas no WhatsApp da equipe técnica. O relatório mensal inclui uso de recursos e pico de alunos.
• Plantão em períodos críticos: vestibular, semana de provas e lançamento de cursos têm equipe escalada sob demanda.
• Ambiente de homologação nos planos Professional e Enterprise, onde dá para testar atualização, plugin e carga sem tocar produção.
• Aviso antes do limite: quando o uso se aproxima do teto do plano, avisamos com antecedência, em geral 60 dias antes de impacto operacional, e a troca entre planos não tem custo.

Os planos vão do Starter (até 500 alunos) ao Professional (até 5.000) e ao Enterprise (mais de 50.000, com load balancer e infraestrutura dedicada). Num desses casos, uma universidade pública teve pico de 4.500 sessões no vestibular sem downtime; em outro, uma rede de escolas saiu de 4,2 s para 1,1 s de TTFB ao trocar hospedagem genérica por uma stack dedicada.

Para contratar, o caminho começa pelo diagnóstico gratuito: analisamos o seu Moodle atual e devolvemos gargalos e proposta em até 3 dias úteis. Se vier de outro fornecedor, a migração assistida leva até 5 dias úteis, com homologação antes da virada. Você solicita pela página de planos de hospedagem Moodle ou direto pelo WhatsApp.

Conclusão: meça antes da prova, não durante

Quantos alunos simultâneos Moodle o seu servidor aguenta não é um número que se descobre na ficha técnica. É um número que se mede: estimativa pela memória e pelo tempo de requisição, ajuste de PHP-FPM, sessão, cache e banco, e um teste de carga em homologação que reproduza a sua pior prova.

Se a próxima avaliação sincronizada está no calendário e você não sabe o limite de alunos simultâneos Moodle do seu ambiente, comece hoje pelo status do PHP-FPM e pelo slowlog. E se preferir que alguém meça, ajuste e responda pelo pico com SLA em contrato, peça o diagnóstico gratuito da hospedagem Moodle da Agathas Web.