Configurando o BBB com 26 participantes simultâneos
A maioria dos tutoriais fala em 10 ou 20 pessoas. A realidade é que 26 participantes coloca o servidor em território onde a documentação oficial já não cobre tudo com conforto. O BigBlueButton suporta oficialmente até 50 participantes em sessões normais, mas o comportamento muda drasticamente entre 20 e 30 pessoas, especialmente no que diz respeito a consumo de banda, codecs e gerenciamento de recursos.
bbb 26 participantes: o que acontece na prática
Com 26 participantes ativos, você está lidando com um cenário onde múltiplos streams de vídeo, áudio contínuo e provavelmente compartilhamento de tela acontecem ao mesmo tempo. O BBB usa WebRTC para vídeo e.audio, e o servidor media (mediasoup, nas versões mais recentes) precisa gerenciar transcodificação e seleção de quem fala. Isso é diferente de uma reunião com 5 pessoas, onde praticamente tudo roda em tempo real sem sobrecarga. O problema que eu enfrentei especificamente aconteceu numa sessão de treinamento com 26 participantes conectados via Wi-Fi instável. Metade da sala tinha upload entre 800kbps e 1,2Mbps. O BBB entrou num ciclo constante de adaptação de qualidade, com participantes alternando entre 360p e 240p a cada 30 segundos, e o áudio ficando cortado por causa do gargalo de upstream. O workaround que funcionou foi configurar o red5 para limitar o bitrate máximo de upload por usuário para 800kbps e ativar o modo de apenas áudio para quem não estava usando câmera, além de forçar o uso do codec VP8 em vez de VP9, que consome menos CPU no servidor de media.
Requisitos mínimos para aguentar 26 participantes
Não adianta tentar rodar isso num VPS barato. Para 26 participantes com vídeo ligado, você precisa de pelo menos 16 vCores e 32GB de RAM dedicados, com SSD NVMe se possível. O BBB armazena logs de sessão, gravações em processamento e buffers de mídia em disco, então disco lento mata a experiência muito rápido. A rede também é crítica. Cada participante com vídeo ativo gera entre 300kbps e 1,5Mbps de tráfego de entrada e saída no servidor, dependendo da resolução e do codec. Com 26 pessoas, estamos falando de 7,8 a 39Mbps de tráfego total só em mídia, sem contar o sinal de controle via WebSocket e SIP. Uma conexão de 1Gbps no servidor é o mínimo aceitável, e o ideal é ter 10Gbps se a carga for constante.
O sistema operacional precisa ser Ubuntu 22.04 LTS ou 24.04 LTS. Eu já vi tentativas com Debian e CentOS que deram problema com dependências do mediasoup e do Kurento. Fique no Ubuntu para evitar dor de cabeça.
Instalação e configuração para essa carga
A instalação padrão via script do BBB funciona, mas para 26 participantes você precisa ajustar alguns parâmetros antes de subir o serviço. O arquivo /etc/bigbluebutton/bbb-conf-sec.sh é o primeiro lugar onde você deve intervenir, configurando SSL corretamente. Depois, vá em /etc/bigbluebutton/bbb-conf.conf e ajuste os valores de timeout e de número de workers. O ajuste mais importante fica em /etc/nginx/conf.d/bigbluebutton.conf. O número de worker_processes precisa ser pelo menos igual ao número de vCores disponíveis, e worker_connections deve ficar em 4096 ou superior. Sem isso, o Nginx começa a rejeitar conexões quando o número de participantes ultrapassa 20, e o sintoma é aqueles "connection reset" aleatórios que todo mundo vê e ninguém sabe explicar.
👉 Clique no botão abaixo para saber mais sobre o assunto!
No kurento.conf.xml, que fica em /usr/share/bbb-web/WEB-INF/classes/, você precisa ajustar os parâmetros de buffer. O valor padrão de max-buffer-length é 1000ms, mas para 26 participantes recomendo subir para 2000ms. Isso reduz o freeze em redes instáveis, embora aumente ligeiramente a latência percebida. O trade-off vale a pena nessa faixa de participantes. O Redis também precisa de atenção. Verifique o maxmemory e o maxmemory-policy no /etc/redis/redis.conf. O BBB usa Redis para sessão e fila de gravação. Se o maxmemory estiver baixo, participantes são desconectados silenciosamente quando o limite é atingido. Coloque pelo menos 4GB e use the allkeys-lru policy.
Pitfalls comuns que iniciantes cometem
O erro mais frequente é achar que porque o BBB suporta 50 participantes oficiais, roda bem com 50. O suporte oficial é uma linha teórica. Na prática, com 26 participantes, o servidor já está trabalhando duro. O problema começa quando você adiciona gravação ativa. Cada gravação em GB ou MP4 consome CPU adicional significativa, e com 26 participantes gravando, o servidor pode travar completamente. Outro erro é não limitar a taxa de quadros. O BBB por padrão permite até 30fps de vídeo, mas muitos clientes enviam 60fps se a webcam permitir. Com 26 pessoas enviando 60fps, o servidor de media gasta o dobro de CPU na transcodificação. Force o limite para 15fps nas configurações de vídeo do BBB, e o resultado será uma experiência muito mais fluida para todos.
Também observe o uso do GPAC para gravação. O GPAC é o motor de conversão de gravações no BBB, e ele é Single-threaded na maioria das configurações. Se você gravar sessões com 26 participantes, uma única gravação pode consumir 100% de um core inteiro por horas. Planeje isso no dimensionamento do servidor.
Alternativas quando o BBB não aguenta
Se depois de tudo isso você ainda tiver problemas de performance com 26 participantes, considere migar para o Jitsi Meet ou usar o BBB apenas como backbone e integrar com o Janus Gateway para o tratamento de mídia. O Janus é mais leve que o mediasoup em cenários de alta concorrência, especialmente quando o foco é transmissão ao invés de interação pesada. Também existe a opção de dividir a sala em sub-salas usando o recurso de Breakout Rooms do BBB. Com 26 participantes, duas salas de 13 pessoas cada reduzem drasticamente a carga no servidor de media, e a experiência individual melhora porque há menos streams competindo por banda e CPU.
O BBB com 26 participantes funciona sim, mas exige que você trate o servidor como um equipamento de produção desde o início, não como um teste. A configuração padrão é para uso educacional leve, e sair dessa zona começa exatamente no número 20 de participantes.
