“Debido a una carga extrema, esto se muestra temporalmente a todos como lo vería un usuario sin iniciar sesión”
Administro un sitio web que presenta hilos en vivo durante partidos de baloncesto y he tenido problemas con el servidor sobrecargándose y mostrando este mensaje durante los partidos (pico de actividad).
¿Hay alguna manera de identificar la mejor forma de abordar el problema? ¿Es la velocidad de almacenamiento? ¿La memoria? ¿La CPU? ¿Hay algo que pueda hacer además de mejorar mi servidor, o si lo hago durante estos momentos… qué debería mejorar?
¿Que haya menos personas usando el foro? Mejor aún sería que distribuyeran su uso en lugar de hacerlo todos durante el juego.
Pero nada de eso es útil. Dado que sabes cuándo se juegan las partidas, podrías mejorar tu servidor solo durante el juego o ejecutar varios servidores durante el juego detrás de un equilibrador de carga.
Necesitas más núcleos de CPU y más rápidos, además de más RAM, para poder aumentar el número de procesos web (Unicorn Workers) y así hacer frente a los picos de tráfico.
Es un área en la que @sam está trabajando activamente. Parece que las versiones más recientes de Discourse han retrocedido en este aspecto, en términos de rendimiento.
Dicho esto, la verdadera solución es utilizar una herramienta de chat en vivo si necesitas interacciones en tiempo real para cientos de personas al mismo tiempo, aunque sigo cuestionando cómo y por qué el chat es “útil” cuando se desplaza tan rápido que nadie puede ver realmente nada, como en las transmisiones de Twitch y YouTube.
Esta fue mi experiencia con un foro de fútbol durante un partido antes de que surgieran los problemas:
Digital Ocean
1 CPU y 1 GB = 30-40 usuarios en una situación similar a un chat
2 CPUs y 2 GB = 70-80 usuarios en una situación similar a un chat
4 CPUs y 8 GB = adecuado para 120 usuarios y 1000 publicaciones en 2 horas. No alcanzó el límite.
Con Hetzner (sitio espejo)
Mi experiencia fue:
3 CPUs (chip AMD CPX 21) y 4 GB = problemas con 20 usuarios
2 CPUs (Intel) y 8 GB = sin problemas con 20 usuarios.
Nunca llegué a probar con más usuarios.
Lo clave es mejorar la CPU y la RAM. Y TAMBIÉN editar el archivo app.yml.
Añade más unicorns aquí y también modifica db_shared_buffers.
En los foros deportivos se acerca más a las actualizaciones de texto en vivo de los partidos. La gente no tanto chatea (aunque ocurre en cierta medida, especialmente en el descanso), sino que recibe una narración en vivo de otros aficionados.
Mucha gente entra al foro simplemente para leer la narración en vivo. Ver los pensamientos y opiniones de los eventos clave del partido por parte de personas destacadas. Desde reacciones divertidas hasta análisis serios.
Si te perdiste el partido, la gente entra simplemente para leer la narración evento por evento. Es genial para quienes están en el trabajo ;). Es más personal y subjetivo que la narración en texto de los periódicos o los canales de televisión.
Un punto importante a tener en cuenta aquí es que las implementaciones de “chat” generalmente transmiten el contenido real a los suscriptores.
En Discourse tenemos un pipeline bastante complejo que hace que la implementación ingenua sea complicada, lo que genera grandes cantidades de tráfico.
Un usuario publica una respuesta.
Todos los usuarios que están viendo el tema descubren mediante transmisión que hay nuevo contenido.
Todos los usuarios solicitan al servidor el contenido de la publicación (100 espectadores = 100 solicitudes).
Extraemos imágenes y las optimizamos.
Todos los usuarios que están viendo el tema descubren mediante transmisión que hay nuevo contenido.
Todos los usuarios solicitan al servidor el contenido de la publicación (100 espectadores = 100 solicitudes).
(Tenemos varias optimizaciones, límites de tasa, reintentos, etc., pero esa es la idea general).
Todas estas solicitudes deben pasar por nuestro pipeline de seguridad para garantizar que el usuario tenga los derechos necesarios para ver la publicación, entre otros aspectos.
Si el contenido fuera algo breve y pudiéramos encontrar una forma de implementar la seguridad de manera más ligera para la “carril rápido”, podríamos distribuir los mensajes de chat mediante transmisión. Esto daría lugar a un rendimiento significativamente mejor; probablemente podríamos manejar 10 000 usuarios en un solo droplet de Digital Ocean de 2 GB con ese diseño.
La seguridad es muy compleja. La caché también lo es debido a los problemas de invalidación de caché.
Así que, sí, definitivamente estamos pensando en este problema. Pero tal como están las cosas…
Muchos espectadores conectados en un solo tema + mucho contenido nuevo en un solo tema = facturas de servidor costosas.
Para ser honesto, solo tengo conocimientos suficientes para ser peligroso. Soy de los que aprenden jugando (y rompiendo). Aprecio enormemente el increíble esfuerzo dedicado a crear esta plataforma. Cuando creé mi primer foro hace 12 meses, probé 12 versiones diferentes Vanilla, MyBB, SMF, Flarum, etc. Discourse fue, con diferencia, el mejor.
Una de las mayores ventajas es el desarrollo activo. Es genial ver cómo ustedes escuchan a la comunidad y mejoran continuamente.
Hola chicos, mi sitio parece haber ido hacia atrás, con el mismo paquete de DO (8gb, 4CPUs), mi sitio está empezando a tener problemas con 60-70 usuarios publicando 1000 publicaciones.
Solo me pregunto dos cosas.
¿Es posible eliminar el mensaje de carga extrema? Parece alarmar más a los usuarios que ser útil.
¿Algún progreso en el manejo de un gran número de usuarios?
Mientras tanto, voy a explorar la modificación de los unicornios y la desactivación de complementos, etc., para ayudar a liberar recursos.
Vanilla, MyBB, SMF, Flarum, etc. Discourse fue, con diferencia, el mejor.
)