Introducción
En nuestro viaje para organizar grandes reuniones virtuales, queríamos determinar la capacidad de un solo fragmento en Jitsi Meet y evaluar su rendimiento en diferentes escenarios. Nos centramos en dos enfoques de investigación distintos: uno implicó organizar una sola conferencia para medir su punto de quiebre, mientras que el otro exploró varias conferencias con un bajo número de participantes en cada una.
Enfoque 1: Organizar una conferencia individual
Configuración del entorno
Nuestra investigación comenzó con la configuración de nuestro entorno de AWS. Implementamos dos servidores: uno dedicado a Jitsi Meet, que incluía Prosody y Jicofo, y el otro asignado para Jitsi Videobridge (JVB). Para nuestra fase de prueba inicial, optamos por un servidor c6a.large, equipado con 2 vCPU y 4 GB de memoria. Dada la naturaleza de un solo subproceso de Prosody, seleccionamos un servidor optimizado para cómputo con solo 2 núcleos para manejar la tarea.
Para dar cabida a aproximadamente 1000-1500 usuarios, utilizamos un servidor c5a.12xlarge dotado de 48 vCPU y de 96 GB de memoria para JVB. Después de una selección minuciosa de servidores, procedimos a instalar Jitsi Meet.
Simulación de la reunión
En Meetrix, aprovechamos nuestro mecanismo de prueba de carga, utilizando bots para replicar situaciones de reuniones reales con usuarios habilitados para video. Nuestro objetivo era identificar cuándo la reunión tendría problemas.
Al configurar Jitsi Meet, designamos una sala de reuniones dedicada (nombre de la sala: load0) exclusivamente para este test de carga, poblada de robots compatibles con video.
Fase 1: 250 participantes
En la fase inicial, agregamos gradualmente 50 bots a la vez, para alcanzar 250 participantes. Monitoreamos de cerca los registros del backend para detectar cualquier anomalía en Prosody, Jicofo, Nginx y JVB. Como hemos constatado el buen funcionamiento de las principales funcionalidades de reunión, pasamos a la fase siguiente.
Fase 2: 500 participantes
Durante la segunda fase, continuamos aumentando el número de robots de 50 en cada ronda hasta alcanzar 500 participantes. Los problemas de backend permanecieron ausentes y la funcionalidad de las reuniones se mantuvo estable, aunque se notaron retrasos menores en la reactividad de los botones.
Fase 3: 750 participantes
Al pasar a la tercera fase, aumentamos el número de participantes a 750, sin encontrar problemas de back-end. Sin embargo, el front-end mostró signos de fatiga, incluyendo interrupciones de video ocasionales y una latencia aumentada.
Fase 4: 1000 participantes
Después de alcanzar 1 000 participantes durante la cuarta fase, el uso de los recursos del servidor, en particular en Prosody, aumentó. Mientras que el back-end permaneció estable, el front-end experimentó una ralentización notable, incluso las operaciones básicas como la apertura de la barra de herramientas tardaron más tiempo.
Fase 5: 1250 participantes - Punto de ruptura
A medida que nos acercábamos a los 1 250 participantes durante la última fase, el rendimiento del front-end se degradó. Los problemas de latencia y usabilidad se hicieron importantes, señalando que habíamos alcanzado el punto de ruptura del sistema.
Conclusión - Enfoque 1
En resumen, nuestras pruebas indican que una sola conferencia en Jitsi Meet sin ninguna personalización puede albergar cómodamente alrededor de 200 a 250 participantes sin encontrar problemas. Es importante tener en cuenta que el rendimiento del navegador de la máquina anfitriona juega un papel esencial en la determinación de este límite; un rendimiento de navegador superior puede permitir albergar más participantes.
Tenga en cuenta que si ha realizado personalizaciones en el frontend, esto puede afectar el rendimiento y la estabilidad de la reunión, lo que dificulta el logro de estos objetivos.
La mayoría de las dificultades encontradas se referían al front-end, ya que no se registraron problemas importantes a nivel del back-end. Esto sugiere que un solo fragmento de Jitsi Meet puede gestionar eficazmente hasta 1 000 participantes, aunque el número preciso puede fluctuar en función de factores como las condiciones de la red y las capacidades del hardware virtual.
Enfoque 2: Organizar múltiples conferencias
Configuración del entorno
En nuestro segundo enfoque, utilizamos el script Terraform de Meetrix para una instalación rápida y económica de una configuración de un solo fragmento. Esta configuración incluía un servidor Jitsi Meet (c6a.large), un servidor Coturn (t3a.micro) y un grupo de escalado automático JVB (cada uno utilizando c6a.xlarge). Como se mencionó en el enfoque anterior, continuamos eligiendo servidores optimizados para el cómputo tanto para el servidor Meet como para los servidores JVB.
Simulación de la reunión
En este enfoque, nuestro objetivo era organizar 100 reuniones, cada una con aproximadamente 10 participantes. Esto nos permitió garantizar que un solo fragmento pudiera gestionar eficazmente 1 000 usuarios, incluso con un número significativo de reuniones simultáneas. Utilizamos el mismo mecanismo de prueba de carga que antes, pero con un número ligeramente inferior de robots compatibles con video (75 %) en comparación con el enfoque anterior (100 %).
Fase 1: 500 participantes (50 reuniones)
Introdujimos alrededor de 100 bots en 10 conferencias. En la primera fase, mientras monitoreábamos de cerca los registros del servidor y de la consola, aumentamos el número de usuarios hasta 500, probando minuciosamente las funcionalidades básicas de la configuración. No se informó de ningún problema, pasamos a la segunda fase.
Fase 2: 1000 participantes (100 reuniones)
Al acoger bots hasta 1000 participantes, observamos de nuevo un funcionamiento fluido sin encontrar problemas. Las funcionalidades de reunión continuaron funcionando de manera transparente en todas las reuniones simultáneas.
Fase 3: 1400 participantes (más de 100 reuniones)
En la tercera y última fase, agregamos más bots, alcanzando finalmente alrededor de 1400 participantes repartidos en 100 reuniones simultáneas. Nos aseguramos cuidadosamente de que las funciones de reunión funcionaran de manera transparente en muchas reuniones. En esta etapa, después de lograr la estabilidad, Prosody parecía consumir casi el 20 % de los recursos del procesador. Manteniendo esta configuración durante varios minutos sin error, concluimos la prueba de carga.
Conclusión - Enfoque 2
En resumen, nuestras pruebas demuestran que un solo fragmento de Jitsi Meet puede gestionar eficazmente 1 000 participantes sin problemas. Es aconsejable utilizar un servidor optimizado para el procesador para Jitsi Meet con el fin de maximizar el rendimiento.
Este enfoque resultó ser más eficaz que el alojamiento de una sola gran conferencia, permitiendo una mejor distribución de la carga y una experiencia de usuario más estable.
Recomendaciones técnicas
| Componente | Configuración recomendada | Justificación |
|---|---|---|
| Servidor Jitsi Meet | c6a.large (2 vCPU, 4 GB) | Optimizado para la naturaleza de un solo hilo de Prosody |
| Jitsi Videobridge | c5a.12xlarge (48 vCPU, 96 GB) | Gestión eficiente de más de 1000 flujos de video |
| Servidor Coturn | t3a.micro | Suficiente para el cruce de NAT |
| Arquitectura recomendada | Varias conferencias pequeñas | Mejor rendimiento que las grandes conferencias únicas |
Factores que influyen en el rendimiento
- Rendimiento del navegador: Un factor crítico para la experiencia del usuario
- Condiciones de la red: Latencia y ancho de banda disponible
- Personalizaciones del frontend: Pueden afectar negativamente el rendimiento
- Configuración del hardware: Se recomiendan servidores optimizados para cómputo
- Distribución de usuarios: Varias conferencias pequeñas frente a una gran conferencia
Referencias
Enfoque 1:
Enfoque 2:
Conclusión general
A medida que continuamos explorando los límites de las reuniones virtuales, Jitsi Meet sigue siendo una solución robusta con el potencial de una escalabilidad aún mayor en el futuro. Nuestras pruebas demuestran claramente que:
- Jitsi Meet puede manejar eficazmente más de 1000 usuarios simultáneos
- La distribución en varias conferencias pequeñas es más eficiente que una sola gran conferencia
- Los servidores optimizados para cómputo son esenciales para el rendimiento
- El frontend suele ser el principal cuello de botella
Frequently Asked Questions
Cuál es el límite recomendado de usuarios para una sola conferencia Jitsi?
Nuestras pruebas indican que una sola conferencia Jitsi puede albergar cómodamente entre 200 y 250 participantes sin problemas importantes, aunque esto depende del rendimiento del navegador y las personalizaciones.
Jitsi puede manejar 1000 usuarios simultáneos?
Sí, Jitsi puede manejar 1000 usuarios simultáneos, pero es más eficiente distribuirlos en varias conferencias en lugar de en una sola sala de reuniones.
Cuáles son los principales cuellos de botella al aumentar el número de usuarios?
Los principales desafíos se relacionan con el frontend (rendimiento del navegador) más que con el backend. Los problemas incluyen mayor latencia, interrupciones de video y lentitud de la interfaz de usuario.
Qué configuración de servidor recomienda para más de 1000 usuarios?
Recomendamos servidores optimizados para cómputo: c6a.large (2 vCPU, 4 GB) para Jitsi Meet y c5a.12xlarge (48 vCPU, 96 GB) para JVB para manejar eficazmente más de 1000 usuarios.
¿Necesitas ayuda para optimizar tu infraestructura Jitsi?
Si buscas apoyo para extender los límites de Jitsi Meet o necesitas ayuda para gestionar más de 1000 usuarios en Jitsi, nuestro equipo está disponible para soporte comercial de Jitsi. Nos especializamos en la optimización de entornos Jitsi Meet para grandes eventos virtuales y podemos ayudarte con la optimización del rendimiento, configuraciones personalizadas y mejoras de escalabilidad.
Contacta a Meetrix
